Re: Another question about codebases and jar versions

Logan, Patrick wrote:
> A class is identified as a unique type by its class loader and the class
> object. Will the class object from the new jar replace the old class,
> and so possibly cause confusing with any lingering instances of the old
> class?

This is the important thing.  Any class which has shared visibility, across
multiple JVMs, must be loaded from a classloader that provides the appropriate
amount of visibility.  Interfaces, which are the heart of most distributed
applications, are almost always loaded from the application class loader (or
some appropriately constant loader).  Only the implementation classes (or
preferred classes as they can also be referred to) should be changing in a
versioned jar.

Maybe another way to say this is, if a Class object (interface, Class, enum etc)
changes in away that affects compilation, it typically can not be
preferred/versioned without restarting things that see that change.  Classes
which implement an interface, or subclass a platform class, can be
preferred/versioned, and will always need to be loaded from the codebase, in
general.

So, if you can wrap your thoughts around two different types of classes,
platform and non-platform, that should help you associate the parallel
classifications of "non-preferred" and "preferred".

A non-preferred class, then is always visible in the application class loader if
that application references the class, or else it could not load the classes
with the references and use them, unless a separate class loader with the
definition was visible through some other mechanism, such as the context class
loader.  Non-preferrred classes can be (and should be really) included in the
-dl.jar, but should be listed in the PREFERRED.LIST file as non-preferred.

Preferred classes are non-platform classes.  They are the reason why mobile code
is powerful.  These are the classes which should be loaded, always, from the
codebase loader so that the intended version of each is used in the operation of
the system.

When you version your codebase with a new implementation, you want that version
loaded and used in its entirety (at least that's the best practice I believe).
So, by naming the URL of that codebase differently, you'll make sure it gets
loaded into a new class loader.

The visibility of that new classloader vs any older version classloader is still
something that your application might have to "worry" about explicitly.  The
context class loader is one of the predominate mechanisms for making sure that
the right classes are loaded as preferred classes.

Managing and maintaining the right context class loader is another issue for
another thread.

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]