On 06/12/2015 20:25, Alan Snyder wrote:
I have been told [1] 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.
Alan
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.
-Alan
