RMIClassLoaderSPI, was: Re: getting a basic class loader
peter.firmstone at zeus.net.au
Mon Dec 7 14:10:53 UTC 2015
Thanks Alan, will check out Alex's talk.
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.
More information about the jigsaw-dev