I am making the decision for an embededded database in an upcoming Java servlet application. I am down to two final contenders: SQLite with SQLiteJDBC “pure Java” drivers vs Java DB (aka Derby).
Here is my killer criteria: The application must run on any OS that supports Java, specifically we have Solaris, CentOS, Windows x86 and Windows x64 hosts that will all need to run the application. And installation must involve nothing more than copying the war file to the target server’s deployment folder and letting the server do the rest (which is nothing more than just copying a zip to the target server and then letting the server unzip and run the app). There should be no mucking around with native binaries as part of the installation, and no additional setup logic. (That’s actually not my requirement, it’s the company’s, for all servlet-based apps, but I do like it).
I know that Derby (Java DB) meets the above criteria. I’ve done it once or twice. But I really like SQLite’s single file architecture and the fact that the SQLite community is about 20 times larger than that of Derby. I also have a fear that Oracle will kill Derby someday, as they now have something like five competing database products under their umbrella and that can’t go on forever. Derby will probably be the first casualty when housekeeping begins.
So, I was looking at SQLiteJDBC, which claims to have “pure Java” JDBC drivers for SQLite. Now, I would understand “pure Java” to mean that there are no OS dependencies or additional libraries, that one can run the driver in any JVM on any OS. So, I go and get the jar file with the pure Java drivers. And being the curious sort, I look inside it. Then I notice it contains 4 files in the root with “.lib” extensions, as follows:
linux-amd64.lib
linux-x86.lib
mac-universal.lib
win-x86.lib
Ok, so, what’s up with that? Are these like native libraries for the named OS’s? If so, can I assume this pure Java driver will only run on a platform with an appropriate lib file in the jar? If that is the case, I lamentably will have to take SQLite out of the list of contenders, because winX64 and Solaris are our two most important OS’s here.
Or maybe I’ve misinterpreted and the pure Java driver really is pure Java and it will run on in any JVM?
All responses welcome!!!
Thanks in advance,
John
If I understand correctly, SQLiteJDBC itself is a Type 4 JDBC driver but still requires some native binary integration to the host operating platform since SQLite is still a C-based solution and does not have a network integration/protocol layer like SQL*Net for Oracle as far as I know. The SQLiteJDBC home page mentions a “NestedVM” implementation for any language supported by GCC, so it appears possible to deploy cross-platform wherever there is GCC runtime environment. There was no mention of Solaris however.