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? Thanks, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Alan Bateman <[email protected]> Sent: 07/12/2015 06:37:55 pm To: Alan Snyder <[email protected]>; jigsaw-dev <[email protected]> Subject: Re: getting a basic class loader 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
