Ed's Big PlansJava Classpaths are Evil
While working with Phylogenetic Analysis Library (PAL) for an alignment problem, I ran into the problem of having to specify classpaths to a jar file… it should have be straight forward enough…
Java classpaths are a pain.
Here are a few observations I’ve made about how to specify them in the command line.
- an Item can either be a directory that contains .class and .java files OR
- an Item can be a .jar file.
- to specify more than one Item.jar in Unix, use:
javac -classpath .:Item1.jar:Item2.jar
- note that you cannot put a space between the colons
- note that you must include an extra Item ‘.’ to specify the current working directory
- note that in Windows, you must use ‘;’ instead of ‘:’
- note that after compiling with javac, the same -classpath and its arguments must then be applied with java
Nuisance? Yes! Necessary Evil? No!
In the compiled Java class, there certainly could have been some metadata implemented that is a copy of the last known classpath string… why is there a disparity between the symbols used in Unix and Windows? … Why aren’t spaces allowed? Why does one have to specify the current working directory?
Evil.
A side effect of not being able to put spaces in between the colons of several paths is that one can’t just put a backslash in to negate a newline– you would need to have the next path start at the very beginning of the next line which is just ugly.
This is one of the many Java screw ups. It was thought that classes were the units of program, so there was never a mechanism to aggregate classes into libraries. JARs became the standard, but they have no metadata to express dependencies or versioning (classes do this individually). So, Java’s dynamic linker works at the class level, not the “module” level, hence, you have to feed it all the places classes might be. This was done much better in .NET where there are DLLs that work like normal libraries, expression module-level dependencies and the dynamic linker can deal with libraries and then with the classes in side them. There is a proposal for a Java module format like this, but I haven’t heard from it in a while.
Sure– that seems rational– I bet Sun would just glue on a module format so that it didn’t interfere with existing functionality. Honestly, why is it so hard to slap a sunset clause onto the Java 1, 2, 5, 6 specification, or offer temporary dual support during a phase out (e.g. Python 2.x, 3.x)?