some plugins rely on this unfortunate behavior
It may be possible to mechanically detect these cases: if the extension class has a declared constructor or a static initializer, then we must assume that was intended as an implicit @Initializer (though we could issue a warning that it would be better made explicit). Of course doing such a check at runtime requires loading, if not fully resolving, the class, which is what we hope to avoid. That is just a small portion of the general problem that when someone asks for the ExtensionList of a particular supertype, we would like to be able to efficiently enumerate all subtypes with @Extension, which is not something we currently have static metadata for (since Jenkins did not use SezPoz as it was designed). We could try to build a cache of this information after starting up with all extensions loaded, so that the next startup will be faster. This does not help JenkinsRule, though, and requires the cache to be invalidated based on the set of enabled plugins and their versions. We could stop using SezPoz for @Extension and instead define custom processor which records supertypes, and try to get plugins released which are built against this system. Means that any older plugins will still get all their extensions loaded eagerly. |
