RMIClassLoaderSPI, was: Re: getting a basic class loader

[Peter Firmstone]

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 <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 [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