Looks fine, there's no functionality change, just a bit of cleanup.

We have had an issue with the auto-injected application object in the past during upgrades from 2.5 to 3.x. That is the case especially for system plugins.
See #3467 for the issue we had back then with the remember me plugin.

Even more reason to make sure that people first upgrade to a version that has this already included and then to upgrade to the version that contains this.

There is no version where you could ensure that. It doesn't even work from 3.1 to 3.2 (when we introduced it imho).

The only way that becomes an issue is if the system plugins are getting initialized before the JPlugin class in libraries/joomla gets removed (which would be locked at 3.1.5 at the latest since it was moved to libraries/cms at 3.2). And based on our autoloader path priorities, libraries/cms gets preferred over libraries/joomla, which to me means that the user is having other upgrade issues than this.

see my comments regarding making the updater more intelligent.

Improving the updater, yes. As you proposed on the mailing list, I don't agree with. I'd almost argue the update component should be the only supported update platform and a CLI script written to support updates in that manner, then enable the component to handle more of the updates and be less reliant on the platform to do it (that's exactly how I implemented my update platform in another project). But, this isn't the forum for that discussion.

@Hackwar to fix it you can use this check at the __construct

        // Get the application if not done by JPlugin. This may happen during upgrades from Joomla 2.5.
        if (!$this->app)
        {
            $this->app = JFactory::getApplication();
        }

Set to "open" on behalf of @zero-24 by The JTracker Application at issues.joomla.org/joomla-cms/5980

Moving back to Pending also on the Tracker

Before we add such code, I'd rather close this PR again. The goal is to reduce the number of LoCs and not increase it. Either this feature works, then we don't need that check, or it does not work, then we should remove it again from the whole system.Simple as that.

@hackwar I am a bit confused on the state of this PR - are you saying you want it to be closed

This PR is meant to simplify code by making usage of the autoload feature for the application object. Since that is not update-safe, it was proposed to introduce even more code to make sure that we can use the application object. Since the goal was to have less code, that would contradict itself. I would still vote to add this PR to the repo, but only without adding additional code.

But if that cant be added without adding the extra code it is not possible is it?

yes and no. The PLT would have to decide if we introduce a step inbetween upgrades from 2.5 to latest 3.x, where we make a stop for example at 3.4.0 or something, where the new code has already been introduced and this issue can't come up anymore. Then in the next step, you would upgrade to the latest version. In that case this code could be merged. At one point in time we will have to introduce something like this, even if it is just so that not every update needs to load and replace ALL files that have been changed since Joomla 1.5...

Setting to Needs Review so that decision can be taken