Well, it's not really day #3. But I've spent a fair amount of time on Friday and over the weekend reading a copy of "The Java Programming Language" to refresh my memory on all this new-fangled Java stuff.
I decided it was time I wrote a stand-alone Java program to do... something. Normally, you'd expect someone to write the standard "Helllo, world." program and build from there. No, not me. That's too easy and likely to work on the first try.
No, for me a good first program is one that connects to MySQL, runs a query, and spits out the results. In this case, the query was to be SHOW DATABASES. As you might guess, that asks MySQL for a list of all the databases it knows about. Think of it as "Hello, MySQL."
So I headed over to the MySQL web site to download Connector/J the official MySQL JDBC driver.
Once it was unpacked and installed, I began working on the code. I had found some example code on-line was close to what I needed, so I adapted it a bit. Once it compiled successfully, I spent a lot of time chasing down a really dumb run-time exception. It seemed that Java could find the driver I had just installed. According to the docs, I could either put a whole directory tree into my CLASSPATH or just use the single JAR file. I opted for the jar file, because it seems cleaner. I'd rather deal with a single file. I'm sure that's a bit of a performance hit, but it's only startup cost and I really don't care about the startup cost. I'll be writing server-side code anyway, so it generally starts once and then runs for a long time.
Anyway, to make a long story short, Sun did something rather stupid. I wasted a good hour because I should have put an explicit reference to the jar file in my $CLASSPATH. It's not sufficient to simply drop the jar file into one of the directories specified in $CLASSPATH.
At this point, I felt like the guy in that one switch parody who, after upgrading to OS X from OS 9, says "What the fuck?!"
Do the morons at Sun (one of the oldest Unix companies!) not realize how Unix path variables normally work? Paths specify directory names, not zip, tar, jar, or any other type of archive files.
Note to Sun: Thanks for breaking 20+ years of tradition so that I could waste an hour scatching my ass on this problem. There's nothing like pulling dumb tricks like this to make the barrier to entry just a little bit higher.
Why can't Java just check all the *.jar files that happen to live in given directory? Is that too damned hard?
Anyway, the good news is that after I fixed that stupid problem (I copied the jar file to $JAVA_HOME/jre/lib/ext instead of endorsing Sun's bad decision), the code worked on the first try. Granted, the code's a bit verbose compared to the Perl equivelant, but it's a nice little class that could be reused in some other simple proof-of-concept code. It all reminds me a bit of learning C++ way back when.
Excellent. My version of "Hello, MySQL." works. That wasn't so hard after all.
Next up, learning a bit more about the JDBC API, connection pooling in Java, and related fun stuff. Oh, I also want to play with Connector/J's failover feature. It sounds like a neat idea that I just might have to implement in DBIx::DWIW for Perl.
Posted by jzawodn at December 22, 2002 11:21 PM
Heh, yah.. did I mention? The reason I have about 2GB worth of source code in my work area is becuase I hate to have to reference every bloody jar I use once and may never again in my CLASSPATH... so I just unpack them into one huge source tree..
Oh, wait until you run into limitations due to CLASSPATH String being too long for some shell scripting.. fun fun fun
I ran into the same problem some time ago, unfortunately I smashed my head against the wall for almost three days.
I would like to know how you find the implementation of the 'failover' stuff in Connector/J. I think I'm the only one that has tested it :)
I'm sure it needs a little polish, maybe a better way to select where to failover to, when to fall back, etc. Maybe for version 3.1.
It is can be annoying but helps if you need to control the order of jar files on the path. Figuring out the magic order because somebody included an older version of some common class in their jar, now that is annoying!
I'm not defending Sun, I'm just hoping to help your geek mind grok the mojo of Java: the idea is that in Java's mind, a jar file isn't a file, but simply a compressed directory like a ".tar.gz". Referring to /stuff/ in your $CLASSPATH doesn't work if your code is in /stuff/code/ right? Well, it's the same for jars. For example "/stuff/code.jar" is exactly same as a "/stuff/code/" directory, just compressed. If you ever have to refer to some resource inside a jar file, or do some zipping/unzipping you'll see how this directory analogy follows through. Thus, in Java, you have to refer specifically to the .jar file in your classpath, since that is just another directory, just packaged up "conveniently" for you. Heh. ;-) This generally goes for .war and .ear files too.
I hope that helps.
-Russ
