getting a basic class loader

[Alan Bateman]

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