« A REST-centric messaging API | Main | Ross Judson: AOP + Rules »

Classpath - fixme

Well I knew the Java CLASSPATHwas a pita, but there seems to be a thing in the air that it needs to be fixed. Here's a few quotes from January:

Ted Leung:

The Java classpath mechanism is probably the number one source of wasted time. Just look in any java related mailing list and you'll find piles of messages related to hosed classpaths. Why isn't there a JSR to replace the classpath mechanism?

James Strachan

Classpaths and ClassLoaders can be very frustrating. The real problem isn't the design of the ClassLoader per se, its we need some packaging mechanism on top of it that can correctly (and automatically) load all the corrent jars for us.

Ted Neward:

All this really does, though, is help underscore how fundamentally broken the Java ClassLoader model really is. CLASSPATH is a gross hack and should be deprecated immediately (as in entirely absent from JDK 1.5 and up), and issues like verisoning and JAR-to-JAR dependencies resolved in a more sane and reasonable fashion. Anybody out there in bloggerland willing to go in with me on a new JSR?

Steve Loughran:

happyaxis.jsp does this for stuff in the Axis webapp; lets us track down situations where things are visible at different levels (and with catalina on java1.4 you do need to install bits of axis at different levels). Code worth stealing (indeed ant -diagnostics) already has. A new JSR? hmmm. How about we just knock a new version of java.exe that ignores CLASSPATH and takes either a classic java command line or an in-file declaration of what to run, like the tag in ant.

Markus Kohler:

What I really would like to do is to tell my build script, that I have project A which depends on B, and whether B exports it's symbols. That's the way one can setup projects in Eclipse. I don't care about whether the jar file name of B has changed lately, that would have to be encapsulated in B's build script. I also do not want to have to adapt the classpath of A just because
someone has splitted A into C and D.

Specifying the classpath in an XML or any other configuration file may improve the situation a little bit, but my idea would be to specify the dependencies within the jar files. Actually the jar file spec already defines a "Class-Path" attribute. This is a step forward, but I think it's not the best solution. Instead of referencing jar-files, one should have identifiers (+ a version number) within each jar file and then should reference only identifiers with an optional version number when specifying dependencies.

Carlos Perez:

Isn't this easily done in Ant, here's an example: [...] In short, you got everything self contained in a single XML file. Better yet, you can leverage ANT's filesets to the tilt, enumerate explicitly your jars or use a query mechanism.


February 2, 2003 01:39 AM

Comments

Ted Leung
(February 2, 2003 08:01 PM #)

I've just blogged the status of a project that Markus Kohler and I are working on to try and solve this problem. ..

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/907

Listed below are links to weblogs that reference Classpath - fixme:

» Music, Jelly and XML pipelines from James Strachan's Radio Weblog
James Strachan: good taste in music . [Read More]

Tracked on December 4, 2003 08:32 PM