On 1/2/2011 11:04 PM, MICHAEL MCGRADY wrote:
On Jan 2, 2011, at 7:49 PM, Dennis Reedy wrote:
I'm sure I'm missing something, but I'm not sure what a modular build has to do
with classloading at this point.
If a jar file is in the local class path and includes an implementation, the
implementation
> it includes is frozen until the VM is rebooted.
It is only frozen, from a client's perspective if the client does not prefer it.
If the client -dl.jar file contains a manifest entry for the preferred list of
classes and lists that class as preferred, then the client can get a newer
version of the class. In containers or other JVMs where clients don't interact
through that class, this works fine. If the application which has downloaded
the client proxies, and is then using this class to interact between them, then
yes, the preferred trick doesn't solve the problem because it then creates class
incompatibility between the client's codebase version and the classpath version.
> I take it this is the issue.
There is a distinct issue with how the JVM manages the lifecycle of classes for
certain uses of those classes.
Peter has discussed inserting sub class loaders and doing other things to
isolate the "jsk-platform" from the "jvm" so that updates could occur. But,
practically, I think that is almost the wrong approach.
If the application is using multiple clients and needs an updated class, it will
likely need to regain access to the clients because their "parent" classloader
chains will refer to the old class loader, so something approaching very close
to a restart is needed based on the current implementation of class loading as
contained in net.jini.pref.*.
If the application is a service, then it also needs to essentially restart
because there will be class loader references spread around inside of it as
"context class loader" references on threads (any proxy provided by a client
service which that service is using, including reggie) etc.
So, in the end, I don't see a very clean way to do this without a lot more
layering of class loaders, and I am not sure how to separate some classes
without putting them into separate jars, or created a new pseudo-preferred list
in the jar that is used to create a secondary class loader which only provides
access to specified subgroups of classes (which should actually resolve in a
parent somewhere) or other groupings.
This classloading business is very important to keep simple and "correct". I
don't like the idea of introducing more complexity to solve a "problem" that
doesn't really occur "often". Instead, we need to make sure that classloading
hierarchies are simple and trivially easy to manage so that subclasses of things
in net.jini.pref can be used to explore other mechanisms by people with the
special case needs.
Gregg
