November 23, 2004

Classpath: another example of Java fighting the common case

Just like handling ZIP files: why doesn’t the classpath work like everyone expects? (Mark and I have talked about this multiple times and today’s combined rant at work prompted this.) Everyone who will run a compiler or anything from the command-line has experience with dropping libraries or binaries in a directory and then adding that directory to some path. (Maybe not old-school Mac people, but they didn’t have much of a command-line, did they?)

So: why can't I just point javac/java to a directory with all my JAR files? Windows works that way: you can drop a DLL into c:/windows and it will be seen by everything that needs it. Unix works that way: you can drop a static or dynamic library into /lib, /usr/lib, or a directory you configure yourself, and it will be seen by everything that needs it.

But not Java. With Java I have to specify every single JAR file or directory with classes I need to compile or run a class. It's dumb, dumb, dumb.

Before you start: yes, I understand that a JAR file is basically a virtual filesystem and that it's fairly elegant if you can use both directories and JAR files on your classpath. WHO CARES? If everyone expects it to work a certain way, shouldn't it just work that way? Do whatever contortions you need to do behind the scenes to make it work that way, just make it so.

Here's a proposal: to preserve backward compatibility keep the -classpath option the way it is. Just add a new one, say -classpathlib, that takes one or more directories and adds all JAR files in the given directories to the classpath. How hard is that?

Next: Fullscreen for writing
Previous: Changing the rules as you go