RMIClassLoaderSPI, was: Re: getting a basic class loader

[Peter Firmstone]

Thanks Alan, will check out Alex's talk.

Regards,

Peter.

Sent from my Samsung device.
  Include original message
---- Original message ----
From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: 08/12/2015 12:01:27 am
To: Peter Firmstone <peter.firmstone at zeus.net.au>; jigsaw-dev <jigsaw-dev at openjdk.java.net>
Subject: Re: RMIClassLoaderSPI, was: Re: getting a basic class loader

On 07/12/2015 13:13, Peter Firmstone wrote: 
> 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? 
> 
In the current proposal then modules are not required to have a  
"location" or be located by a URI. There are modules generated  
dynamically for things like proxies and dynamic languages that don't  
have locations for example. There isn't anything in the API to locate  
class loader objects by URI. 

Alex's "Under the Hood" talk is a good talk to go through and understand  
the relationship between class loaders and modules (or module layers) in  
the current proposal. In general, Jigsaw places very few restrictions on  
how modules are mapped to class loaders and those restrictions are  
really just stem from fundamental constraints on how class loading works. 

As regards the built-in class loaders (boot, extension, application)  
then they continue to do hierarchical/parent-delegation when loading  
types in unnamed modules. They use direct delegation when loading types  
in named modules. This may or may not be interesting to what you are  
doing as the built-in class loaders are not URLClassLoader objects. Also  
the CodeSources are unlikely to have a host component in the URI. 

-Alan.