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.
