This post originated from an RSS feed registered with Java Buzz
by Chris Winters.
Original Post: Classpath: another example of Java fighting the common case
Feed Title: cwinters.com
Feed URL: http://www.cwinters.com/search/registrar.php?domain=jroller.com®istrar=sedopark
Feed Description: Chris Winters on Java, programming and technology, usually in that order.
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?
Previous Topic
