Domanda

sto prendendo la decisione per un database embededded in una prossima applicazione servlet Java. Sono giù a due contendenti finali:. SQLite con SQLiteJDBC "puro Java" driver vs Java DB (aka Derby)

Ecco i miei criteri di assassino: L'applicazione deve essere eseguito su qualsiasi sistema operativo che supporti Java, in particolare abbiamo Solaris, CentOS, di Windows x86 e Windows x64 host che saranno tutti bisogno per eseguire l'applicazione. E l'installazione deve coinvolgere altro che copiare il file di guerra alla cartella di distribuzione del server di destinazione e lasciare che il server faccia il resto (che è niente di più di una semplice copia di un lampo al server di destinazione e poi lasciare che l'unzip server ed eseguire l'applicazione). Non ci dovrebbero essere gingillarsi con binari nativi come parte dell'installazione, e nessuna logica configurazione aggiuntiva. (Che in realtà non la mia richiesta, è della società, per tutte le applicazioni basate su servlet, ma mi piace di esso).

So che Derby (Java DB) soddisfa i criteri di cui sopra. L'ho fatto una volta o due. Ma mi piace molto l'architettura singolo file di SQLite e il fatto che la comunità SQLite è circa 20 volte più grande di quella di Derby. Ho anche un timore che Oracle ucciderà Derby un giorno, mentre ora hanno qualcosa come cinque concorrenti prodotti di database sotto il loro ombrello e che non possono andare avanti per sempre. Derby sarà probabilmente la prima vittima quando inizia la pulizia.

Quindi, stavo guardando SQLiteJDBC, che sostiene di avere i driver "pure Java" JDBC per SQLite. Ora, vorrei capire "puro Java" per significare che non ci siano dipendenze del sistema operativo o librerie aggiuntive, che si può eseguire il driver in qualsiasi JVM su qualsiasi sistema operativo. Così, vado e ottenere il file jar con i driver Java puro. Ed essendo il tipo curioso, mi guardo dentro. Poi mi accorgo che contiene 4 file nella directory principale con le estensioni "lib", come segue:

linux-amd64.lib
linux-x86.lib
mac-universal.lib
win-x86.lib

Ok, allora, che cosa c'è in questo? Sono questi, come le librerie native per il nome del sistema operativo? Se è così, posso assumere questo driver puro Java verrà eseguito solo su una piattaforma con un file lib appropriata nel vaso? Se questo è il caso, io purtroppo dovrà prendere SQLite fuori dalla lista dei contendenti, perché winX64 e Solaris sono i nostri due OS più importante è qui.

O forse ho interpretato male e il driver Java puro è davvero puro Java e funzionerà su qualsiasi JVM?

Tutte le risposte benvenuti !!!

Grazie in anticipo, John

È stato utile?

Soluzione

Se ho capito bene, SQLiteJDBC per sé è un driver JDBC di tipo 4, ma richiede ancora un po 'l'integrazione nativa binario alla piattaforma operativa ospite poiché SQLite è ancora una soluzione C-based e non dispone di un layer di integrazione di rete / protocollo come SQL * net per Oracle per quanto ne so. La home page SQLiteJDBC menziona un'implementazione "NestedVM" per qualsiasi lingua supportata da GCC, in modo che appaia possibile implementare cross-platform ovunque vi sia ambiente di runtime GCC. Non c'era alcuna menzione di Solaris però.

Altri suggerimenti

http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC -. fornisce un'implementazione Java puro, anche se non usa la condizione lib file, se possibile, in quanto sono più veloci

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top