From what I tested, ServiceLoader doesn't allow a custom classloading
scheme for named modules (step 1 of
http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-).
Its own scheme relies on checking modules loaded by the given
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
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
Under what circumstances would a plugin not want the platform classloader?
Chas
> On Jun 25, 2017, at 12:40 PM, Robert Scholte wrote:
>
> Hi Guillaume,
>
> I don't know all the details about the Platform classloader, but it has been
> introduced with a reason.
> So I
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
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