Can you explain little more why plugins won't see classes loaded by maven core or maven core extensions classloaders? This is implemented in classwords and I was under impression that java9 still allowed custom classloading schemes like what we do or like what OSGi does.
-- Regards, Igor On Sun, Jun 25, 2017, at 07:08 PM, Guillaume Boué wrote: > > Le 25/06/2017 à 22:03, Chas Honton a écrit : > > Under what circumstances would a plugin not want the platform classloader? > > > > Chas > > Thinking about this more, with the current situation, it actually means > that potential providers, located in named modules loaded for example by > Maven core classloader or extension classloader, will not be available > to plugins using ServiceLoader. So this is bigger than platform > classloader. As Robert said, I think there needs to be a way for plugins > to know about modules. > > Reading more into the docs, this may be possible using a ModuleLayer. > Each plugin would have its own module layer composed of modules found in > its dependencies. Their parent would be a module layer associated to > Maven core, and its parent would be the boot layer. This would solve the > ServiceLoader issue for named modules in a plugin realm, since it would > locate providers in all modules in the module layer of the plugin, and > then do the same for their parents, up to the boot layer. However, for > it to work, I'm not sure if this implies that everything be made modular > (plugins and Maven itself). I will try to do some testing on this. > > Guillaume > > > > >> On Jun 25, 2017, at 12:40 PM, Robert Scholte <rfscho...@apache.org> wrote: > >> > >> Hi Guillaume, > >> > >> I don't know all the details about the Platform classloader, but it has > >> been introduced with a reason. > >> So I don't think we should switch to it by default. I think the plugin is > >> well aware which classloaders / modules it wants to use (it should be), so > >> I think we need to find a mechanism for plugins to select their > >> classloaders and modules. > >> > >> thanks, > >> Robert > >> > >>> On Sun, 25 Jun 2017 17:19:07 +0200, Guillaume Boué <gb...@apache.org> > >>> wrote: > >>> > >>> Hi, > >>> > >>> With the introduction of modules in JDK 9, there were changes with > >>> regard to how classloading works, and this impacts class realms created > >>> in Maven. Today, the parent (as per ClassLoader.getParent()) of a class > >>> realm is null, which represents the bootstrap classloader. In JDK 9, the > >>> change is that some classes were moved to a named module other than > >>> java.base, and they are not loaded with the bootstrap classloader > >>> anymore, but with the platform classloader (which was previously the > >>> extension classloader, see JDK-814637). > >>> > >>> This has consequences, like MANTRUN-200, where locating providers with > >>> the ServiceLoader API, using the plugin class realm, will miss JDK > >>> internal implementation classes. In the case of MANTRUN-200, it is > >>> Nashorn of the jdk.scripting.nashorn module, that cannot be found > >>> because of the way ServiceLoader works > >>> http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-. > >>> During the search in named modules, the class realm will not be able to > >>> use its strategy since that process relies on parent delegation > >>> implemented as explicit calls to ClassLoader.getParent() > >>> (http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062), > >>> which, for a class realm, corresponds to the base classloader, i.e. the > >>> bootstrap classloader. And since the Nashorn script engine factory was > >>> loaded with the platform classloader, it is missed. > >>> > >>> It seems that the fix here would be to make all class realms have as > >>> base classloader the platform classloader starting with JDK 9, instead > >>> of the bootstrap classloader (there is a new utility method in > >>> ClassLoader to obtain the platform classloader). I verified that this > >>> solves the problem described in MANTRUN-200, but before I create an MNG > >>> issue, I'm wondering if this is the correct approach. > >>> > >>> What do you think of this change to class realms? The other possibility > >>> I can think of would be to have a way in the JDK to override the search > >>> in named modules, so that our ClassRealm can also delegate to its parent > >>> classloader. It is possible for unnamed modules (since the search > >>> process then relies on the ClassLoader.getResources method, that can be > >>> overriden) but it doesn't look like (and probably intentionally so) to > >>> be possible for named modules. > >>> > >>> Guillaume > >>> > >>> > >>> --- > >>> L'absence de virus dans ce courrier électronique a été vérifiée par le > >>> logiciel antivirus Avast. > >>> https://www.avast.com/antivirus > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
