Les pilotes purs Java SQLiteJDBC vraiment pur?

Question

Je prend la décision d'une base de données embededded dans une application Java servlet à venir. Je suis jusqu'à deux prétendants finaux. SQLite avec SQLiteJDBC Pilotes "pur Java" vs Java DB (alias Derby)

Voici mes critères tueuses: L'application doit fonctionner sur tout système d'exploitation supporte Java, plus précisément nous avons Solaris, CentOS, hôtes de Windows x86 et Windows x64 qui ont tous besoin d'exécuter l'application. Et l'installation doit impliquer rien de plus que de copier le fichier de guerre au dossier de déploiement du serveur cible et de laisser le serveur faire le reste (ce qui est rien de plus que de copier simplement un zip sur le serveur cible, puis laisser le Décompressez serveur et exécuter l'application). Il ne faut pas bidouiller avec des binaires natifs dans le cadre de l'installation, et aucune logique de configuration supplémentaire. (C'est en fait pas mon exigence, il est de, pour toutes les applications à base de servlets, mais je aime la compagnie elle).

Je sais que Derby (Java DB) répond aux critères ci-dessus. Je l'ai fait une ou deux fois. Mais je vraiment l'architecture unique fichier SQLite et le fait que la communauté SQLite est environ 20 fois plus grand que celui de Derby. J'ai aussi une crainte que Oracle va tuer un jour Derby, car ils ont maintenant quelque chose comme cinq produits de base de données en compétition sous leur parapluie et qui ne peuvent pas durer éternellement. Derby sera probablement la première victime quand le ménage commence.

Alors, je regardais SQLiteJDBC, qui prétend avoir « pures Java » pilotes JDBC pour SQLite. Maintenant, je comprendrais « Java pur » signifie qu'il n'y a pas de dépendances OS ou des bibliothèques supplémentaires, que l'on peut exécuter le pilote dans une machine virtuelle Java sur un système d'exploitation. Alors, je vais chercher le fichier jar avec les pilotes purs Java. Et étant le genre curieux, je regarde à l'intérieur. Ensuite, je remarque qu'il contient 4 fichiers dans la racine avec des extensions « .lib », comme suit:

linux-amd64.lib

linux-x86.lib
mac-universal.lib
gagnant-x86.lib

Ok, donc, ce qui se passe avec ça? Sont-ils comme les bibliothèques natives pour le système d'exploitation nommé de? Si oui, puis-je prendre ce pilote pur Java ne fonctionne que sur une plate-forme avec un fichier lib approprié dans le pot? Si tel est le cas, je dois prendre lamentablement SQLite sur la liste des candidats, parce que winX64 et Solaris sont nos deux OS le plus important est ici.

Ou peut-être que je l'ai mal interprété et le pilote Java pur est vraiment pur Java et il fonctionnera dans une machine virtuelle Java?

Toutes les réponses bienvenues !!!

Merci à l'avance, John

Answer 1

Si je comprends bien, SQLiteJDBC lui-même est un pilote JDBC de type 4, mais nécessite encore une certaine intégration binaire natif de la plate-forme d'exploitation hôte depuis SQLite est encore une solution à base de C et ne dispose pas d'une couche d'intégration réseau / protocole comme SQL * net pour Oracle autant que je sache. La page d'accueil SQLiteJDBC mentionne une mise en œuvre « NestedVM » pour toute langue prise en charge par GCC, il semble donc possible de déployer multiplateforme partout où il y a environnement d'exécution GCC. Il n'y avait aucune mention de Solaris cependant.

Answer 2

http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC -. fournit une implémentation Java pur, bien qu'il ne l'utilise fourni .lib fichiers si possible car ils sont plus rapides