RMIClassLoaderSPI, was: Re: getting a basic class loader
peter.firmstone at zeus.net.au
Mon Dec 7 13:13:03 UTC 2015
Just a quick one, now that all modules have URI annotations, is there a tool or utility to find the correct ClassLoader during deserialisation and unmarshalling with RMI?
We've got our own RFC3986 compliant URLClassLoader, that overrides CodeSource to ensure that URL isn't used as a key in SecureClassLoader's cache.
The benefit is CodeSource identity is based on a normalized RFC3986 compliant address and Certificates, not on a DNS resolved IP address.
Will there be new ClassLoader api?
We also mostly thread confine class loading (1 thread per ClassLoader) to avoid ClassLoader monitor contention, which reduces class loading overhead to less than 1% cpu. Previously class loading was hierarchical, now I'm guessing that ClassLoading isn't hierarchical with Jigsaw?
Will there be an api method to find ClassLoaders using their URI annotation in java 9?
Sent from my Samsung device.
Include original message
---- Original message ----
From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: 07/12/2015 06:37:55 pm
To: Alan Snyder <javalists at cbfiddle.com>; jigsaw-dev <jigsaw-dev at openjdk.java.net>
Subject: Re: getting a basic class loader
On 06/12/2015 20:25, Alan Snyder wrote:
> I have been told  that doing something like String.class.getClassLoader() is a good way to get a value that can specified as the parent of a custom class loader when my goal for the custom class loader is to exclude application-specific classes (e.g. from the classpath).
> Is this the best way to accomplish that goal, and does the answer change in JDK 9 with jigsaw?
> I am skeptical because I don’t see any reason to believe that the class loader for any given JDK class is necessarily a complete class loader that knows about all JDK runtime classes. In fact, in JDK 8 it is clearly not the case because the extensions class loader is not included.
Assuming "system classes" means the platform/Java SE API then
historically delegating to the boot loader would have been enough
because the defining loader for all these types was the boot loader.
This has changed in JDK 9 by way of an effort that we have call
"de-privileging". It essentially amounts to moving modules that have no
business being defined to the boot loader and moving them to the
extension class loader with reduced permissions. JEP 261 has the list of
the modules that have been moved so far. There are a few ties to
modules, one of which is that it is highly desirable to have the
upgradeables modules moved out boot loader (for upgradeable modules then
think APIs that are shared between Java SE and Java EE and where app
servers need to run with versions of these APIs that completely replace
the subset defined by Java SE).
So the extension class loader gets a new lease of life and in the JEP
then you will see that we are looking rename it. To your question, then
there is an argument for a ClassLoader::getPlatformClassLoader or some
such method that you have visibility to all platform/Java SE types.
More information about the jigsaw-dev