Today, I rant about Sun's blunder in their bundling of JavaDB in JDK 6. Executive summary: 1. Don't rely on JavaDB being present in the JDK. 2. A bungled bundle is worse than no bundle at all.
When JDK 6 was released, there was a lot of buzz about the bundling of Derby, erm, JavaDB: buzz, buzz, buzz. Of course, there also was some bile. Programmer opinion was mixed. My personal feeling (recorded here for posterity) was “Doesn't the Java team have better things to do?”
But so what—once the deed was done, I felt that I might as well take advantage of the bundled database. In a couple of books, I suggested that readers download JDK 6 and put jdk/lib/db/derby.jar onto the classpath. The publisher of my college text developed a nifty tool for homework checking that is deployed with Java Web Start. It allows students to run sanity checks on their homework assignments, and it uploads the solutions and the results of the checks to the professor's gradebook. For database problems, it simply uses jdk/lib/db/derby.jar.
All was peachy until Java SE 6u2.
Now, out of a sudden, the rules have changed. According to Sun,
“This distribution bundles Java DB, Sun Microsystems' distribution of the Apache Derby pure Java database technology. Default installation locations are:
The reality is a bit more complex.
On Linux, JavaDB is no longer included in the Sun JDK download. It may be that they hope that Ubuntu and others add it to their package, but Ubuntu doesn't even use the /opt directory.
On Windows, the installer charmingly continues making the jdk/lib/db directory, but it leaves it empty. Users can select where they want JavaDB installed (with C:\Program Files\Sun\JavaDB as the default). You can find their decision in the registry (HKLM\Sun Microsystems\JavaDB). Except that the uninstaller doesn't remove the registry entry, so you don't want to rely on it.
I have no idea what Apple does with their JDK for the Mac, but I would love to know.
The takeaway from this sorry episode is: