The Artima Developer Community
Sponsored Link

Weblogs Forum
Subduing CLASSPATH

26 replies on 2 pages. Most recent reply: Mar 11, 2007 3:40 PM by Michael Easter

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 26 replies on 2 pages [ « | 1 2 ]
James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Subduing CLASSPATH Posted: Aug 23, 2006 12:58 PM
Reply to this message Reply
Advertisement
> I did. And I decided to rewrite a lot of code in order to
> solve the dependecies correctly.
>
> I didn't even bother to look at ways to hack a quick fix
> in. My experience is that versioning problems must be
> addressed fully and correctly ASAP.

If there are incompatible versions of the same class, then I believe the only work-around involves using multiple classloaders.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Subduing CLASSPATH Posted: Aug 23, 2006 4:53 PM
Reply to this message Reply
> > I did. And I decided to rewrite a lot of code in order to
> > solve the dependecies correctly.
> >
> > I didn't even bother to look at ways to hack a quick fix
> > in. My experience is that versioning problems must be
> > addressed fully and correctly ASAP.
>
> If there are incompatible versions of the same class, then
> I believe the only work-around involves using multiple
> classloaders.

One of the issues with the default class loaders in java is that they always look up the tree first, before resolving locally, in an attempt to share common code, so that commonly referenced classes, between bits of the application will be compatible. This works for shared data, but is not desireable for classes that are the implementation details.

There are lots of class loader tricks around. The Jini platform has a PreferredClassLoader which lets you manage versioning explicitly. You can place a PREFERRED.LIST into the first jar in the set of jars passed to this class loader. That file will be consulted for resolving classes and you can say "always use my version of ..." for classes as well as whole packages.

This, is something that I think should be available in Java as a standard part of the system so that a jar can fully isolate itself from versioning issues.

Gregg Wonderly

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Subduing CLASSPATH Posted: Aug 24, 2006 5:55 AM
Reply to this message Reply
> There are lots of class loader tricks around. The Jini
> platform has a PreferredClassLoader which lets you manage
> versioning explicitly. You can place a PREFERRED.LIST
> into the first jar in the set of jars passed to this class
> loader. That file will be consulted for resolving classes
> and you can say "always use my version of ..." for classes
> as well as whole packages.

Will it allow to resolve to one verison of a class at one time and then another version at another time, depending on the context of the request? That's the versioning issue I am thinking about.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

The easy way to crack this nut Posted: Aug 24, 2006 7:40 PM
Reply to this message Reply
is to write your own ClassLoader. Its not that hard and when you're asked for a class, you try the default behavior, then if that fails, you do your own search for the class using any kind of rules you like. Load them from the db, read them from a jar, grab them over http, whatever you like.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The easy way to crack this nut Posted: Aug 25, 2006 6:15 AM
Reply to this message Reply
> is to write your own ClassLoader. Its not that hard and
> when you're asked for a class, you try the default
> behavior, then if that fails, you do your own search for
> the class using any kind of rules you like. Load them
> from the db, read them from a jar, grab them over http,
> whatever you like.

That doesn't solve the problem I state above or at least you have not explained how it would.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Subduing CLASSPATH Posted: Aug 25, 2006 6:33 AM
Reply to this message Reply
> > There are lots of class loader tricks around. The Jini
> > platform has a PreferredClassLoader which lets you
> manage
> > versioning explicitly. You can place a PREFERRED.LIST
> > into the first jar in the set of jars passed to this
> class
> > loader. That file will be consulted for resolving
> classes
> > and you can say "always use my version of ..." for
> classes
> > as well as whole packages.
>
> Will it allow to resolve to one verison of a class at one
> time and then another version at another time, depending
> on the context of the request? That's the versioning
> issue I am thinking about.

The context class loader can be used (no should be used in the current design of java class loading in the JVM) to aim class loading requests at specific class loaders. One of the other things that is in Jini is the httpmd classloader which uses an MD5 sum annotation on the end of the URL to provide integrity from man-in-the-middle attacks. It also, as a sideeffect, provides explicit versioning of jar files so that the same service can evolve to a new codebase and advertise a new jar. new clients of that service will see the new jar in the codebase of there marshalled objects, and the JVM download caching and jar file caching will be subverted because of the new URL/name on the codebase jar(s). Thus, multiple clients in the same JVM can see the server evolve, and each will get a new classloader to use as their respective context classloader.

Michael Warres has some good information on network classloading in http://research.sun.com/techrep/2006/smli_tr-2006-149.pdf

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Subduing CLASSPATH Posted: Aug 25, 2006 6:55 AM
Reply to this message Reply
> The context class loader can be used (no should be used in
> the current design of java class loading in the JVM) to
> aim class loading requests at specific class loaders.

I curious how it determines the context inside a VM (not necessarily a app server.) Query the stack?

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Subduing CLASSPATH Posted: Aug 25, 2006 8:18 AM
Reply to this message Reply
> > The context class loader can be used (no should be used in
> > the current design of java class loading in the JVM) to
> > aim class loading requests at specific class loaders.
>
> I curious how it determines the context inside a VM (not
> necessarily a app server.) Query the stack?

Thread.currentThread().getContextClassLoader() is used by libraries to make sure that they load classes from the applications intended location. You can set the context classloader at any time using

Thread.currentThread().setContextClassLoader(ClassLoader) if you have permissions based on the active Policy.

If you want to download some code from a remote server, in your application, you might do the following to establish
a new context class loader that provides access to your
classes, and which delegates up the tree of existing
loaders already active in the application.

URL[]urls = new URL[] {
new URL("http://myserver/path/to/my.jar")
};

// Create classloader, parenting it to the current
// context class loader.
URLClassLoader ld = new URLClassLoader( urls,
Thread.currentThread().getContextClassLoader() );

Thread.currentThread().setContextClassLoader( ld );

To make class equality work 'better' for the average case, the delegation model in the JVM classloaders is look to the parent first. The preferred classloader, that I discussed earlier, would instead consult the preferred list, and if the class is preferred, it would load it from its jars (its a URLClassLoader subclass), instead of looking to the parent.

This preferring of particular classes helps manage intra jar dependencies much more readily than with the URLClassLoader, where you'd have to do some explicit loading, from inside your classes, to get exactly what you needed from the right classloader(s).

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: The easy way to crack this nut Posted: Aug 25, 2006 11:25 AM
Reply to this message Reply
A class loader is a namespace and context. You cannot resolve to one class of a given name at one time and another class of the same name at another time for the same instance of a class loader.

Further, you're only going to be called once for each class within a given instance of a classloader because it is its own context and once the class is loaded, there is no reason to reload it for that context.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: The easy way to crack this nut Posted: Aug 25, 2006 12:02 PM
Reply to this message Reply
> A class loader is a namespace and context. You cannot
> resolve to one class of a given name at one time and
> another class of the same name at another time for the
> same instance of a class loader.

Newer JVM features do allow the class to be changed at runtime, and this is a versioning issue. The opportunity to switchout physical class data is there, but perhaps not a direct feature of the classloader's API.

> Further, you're only going to be called once for each
> class within a given instance of a classloader because it
> is its own context and once the class is loaded, there is
> no reason to reload it for that context.

Right. Each time a new class is referenced by a classloader, the resolution of that class has to occur in the context of that classloader. Thus, you can cause new versions of classes to be resolved by using a changing child classloader as the context classloader, or literally as the loader argument to Class.forName( cls, true, loader ).

The parent of that changing classloader can perform varied resolution of the class by using a private interface between the two loaders that allows the child loader to be known to the parent or the child can just do the loading itself.

Typically, the parent would do the loading if there were classes which must be shared between various child loaders so that Class.equals() could be maintained.

There are lots of details. None of it is really magic, just some indepth knowledge is needed to get through those details.

Ivan Balashov

Posts: 1
Nickname: vanyatka
Registered: Oct, 2006

Re: Subduing CLASSPATH Posted: Oct 20, 2006 6:14 PM
Reply to this message Reply
Hi Bruce & all, thanks for your blog.

I doubt that putting a huge pile of jars in a runtime /ext folder (or C:/jar, that's even worse, root context is too precious for that) is a good way of handling classpath setup. You may soon end up having rather weird problems, caused by globally shared classes, which simply are not compartible. Where possible and in case of problems, I'd include each library manually for each different application.

About fixing classpath using 3rd party tool. Surely, it can be used if the global classpath is swollen of entries. But, I'd rather use java command line switch and save the command line into a bat file (or shell file), to run next times.

Michael Easter

Posts: 3
Nickname: codetojoy
Registered: Mar, 2007

Re: Subduing CLASSPATH Posted: Mar 11, 2007 3:40 PM
Reply to this message Reply
I am late to the party here but I have had similar attempts to lasso the CLASSPATH. Mine are much simpler and can use either Java or Python. They are "read-only"; I think I prefer them because of this. They just provide info.

(1) "which" -- Inspired by the Unix command, this tool takes a search-string and iterates through each jar in the CLASSPATH by examining its file/entry list. If the search-string is found, the name of the jar is printed out to the user.

(2) "split" -- A tiny webpage that takes a string and a delimiter: and simply calls "split" to break out the fields. This is a great way to see Windows variables like PATH and CLASSPATH. (editorial: i can't believe we have a tiny, 1-line editor for env variables in 2007)

Flat View: This topic has 26 replies on 2 pages [ « | 1  2 ]
Topic: Subduing CLASSPATH Previous Topic   Next Topic Topic: Recording of Java/Flex eSeminar

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use