JNA sembra un po 'più facile da usare per chiamare il codice nativo rispetto a JNI. In quali casi useresti JNI su JNA?
Risposte:
Questi sono i problemi che ho riscontrato. Forse c'è di più. Ma in generale le prestazioni non sono così diverse tra jna e jni, quindi ovunque tu possa usare JNA, usalo.
MODIFICARE
Questa risposta sembra essere abbastanza popolare. Quindi ecco alcune aggiunte:
Quindi, continuo a credere che, ove possibile, sia meglio usare JNA o BridJ e tornare a jni se le prestazioni sono critiche, perché se è necessario chiamare frequentemente le funzioni native, il calo delle prestazioni è evidente.
JNIEXPORTfunzioni globali . Attualmente sto esplorando JavaCpp come opzione, che utilizza JNI, ma non credo che JNI vanilla lo supporti. C'è un modo per chiamare le funzioni membro C ++ usando JNI vaniglia che sto trascurando?
È difficile rispondere a una domanda così generica. Suppongo che la differenza più evidente sia che con JNI la conversione del tipo è implementata sul lato nativo del bordo Java / nativo, mentre con JNA la conversione del tipo è implementata in Java. Se ti senti già abbastanza a tuo agio con la programmazione in C e devi implementare del codice nativo da solo, presumo che JNI non sembrerà troppo complesso. Se sei un programmatore Java e hai solo bisogno di richiamare una libreria nativa di terze parti, l'uso di JNA è probabilmente il percorso più semplice per evitare i problemi forse non così ovvi con JNI.
Sebbene non abbia mai valutato le differenze, lo farei a causa del design, almeno supponiamo che la conversione del tipo con JNA in alcune situazioni funzionerà peggio che con JNI. Ad esempio, quando si passano gli array, JNA li convertirà da Java a nativi all'inizio di ogni chiamata di funzione e di nuovo alla fine della chiamata di funzione. Con JNI, puoi controllarti quando viene generata una "vista" nativa dell'array, creando potenzialmente solo una vista di una parte dell'array, mantenere la vista su più chiamate di funzione e alla fine rilasciare la vista e decidere se vuoi per conservare le modifiche (potenzialmente richiedendo di copiare i dati indietro) o scartare le modifiche (nessuna copia richiesta). So che puoi utilizzare un array nativo tra le chiamate di funzione con JNA utilizzando la classe Memory, ma ciò richiederà anche la copia della memoria, che potrebbe non essere necessario con JNI. La differenza potrebbe non essere rilevante, ma se l'obiettivo originale è aumentare le prestazioni dell'applicazione implementando parti di esso nel codice nativo, l'utilizzo di una tecnologia bridge con prestazioni peggiori non sembra essere la scelta più ovvia.
Questo è solo ciò che riesco a tirar fuori dalla mia testa, anche se non ne sono un utente pesante. Sembra anche che potresti evitare JNA se volessi un'interfaccia migliore di quella che forniscono, ma potresti codificarla in java.
A proposito, in uno dei nostri progetti, abbiamo mantenuto un'impronta JNI molto piccola. Abbiamo usato buffer di protocollo per rappresentare i nostri oggetti di dominio e quindi avevamo solo una funzione nativa per collegare Java e C (quindi ovviamente quella funzione C avrebbe chiamato un mucchio di altre funzioni).
Non è una risposta diretta e non ho esperienza con JNA, ma quando guardo i progetti che utilizzano JNA e vedo nomi come SVNKit, IntelliJ IDEA, NetBeans IDE, ecc., Tendo a credere che sia una libreria abbastanza decente.
In realtà, penso sicuramente che avrei usato JNA invece di JNI quando dovevo perché sembra davvero più semplice di JNI (che ha un processo di sviluppo noioso). Peccato, JNA non è stato rilasciato in questo momento.
Se desideri prestazioni JNI ma sei scoraggiato dalla sua complessità, potresti prendere in considerazione l'utilizzo di strumenti che generano automaticamente collegamenti JNI. Ad esempio, JANET (disclaimer: l'ho scritto io) consente di combinare codice Java e C ++ in un unico file sorgente, e ad esempio effettuare chiamate da C ++ a Java utilizzando la sintassi Java standard. Ad esempio, ecco come stampare una stringa C sull'output standard Java:
native "C++" void printHello() {
const char* helloWorld = "Hello, World!";
`System.out.println(#$(helloWorld));`
}JANET quindi traduce il Java incorporato nel backtick nelle chiamate JNI appropriate.
In realtà ho fatto alcuni semplici benchmark con JNI e JNA.
Come altri hanno già sottolineato, JNA è per comodità. Non è necessario compilare o scrivere codice nativo quando si utilizza JNA. Il caricatore di librerie nativo di JNA è anche uno dei migliori / più facili da usare che abbia mai visto. Purtroppo, a quanto pare non puoi usarlo per JNI. (Ecco perché ho scritto un'alternativa per System.loadLibrary () che utilizza la convenzione del percorso di JNA e supporta il caricamento senza interruzioni dal classpath (cioè i jar).)
Le prestazioni di JNA, tuttavia, possono essere molto peggiori di quelle di JNI. Ho fatto un test molto semplice che ha chiamato una semplice funzione di incremento intero nativo "return arg + 1;". I benchmark eseguiti con jmh hanno mostrato che le chiamate JNI a quella funzione sono 15 volte più veloci di JNA.
Un esempio più "complesso" in cui la funzione nativa riassume un array intero di 4 valori mostrava ancora che le prestazioni JNI sono 3 volte più veloci di JNA. Il vantaggio ridotto era probabilmente dovuto al modo in cui accedi agli array in JNI: il mio esempio ha creato alcune cose e le ha rilasciate di nuovo durante ogni operazione di somma.
Codice e risultati dei test possono essere trovati su github .
Ho studiato JNI e JNA per il confronto delle prestazioni perché dovevamo decidere che uno di loro chiamasse una dll nel progetto e avevamo un vincolo di tempo reale. I risultati hanno mostrato che JNI ha prestazioni maggiori di JNA (circa 40 volte). Forse c'è un trucco per migliorare le prestazioni in JNA, ma è molto lento per un semplice esempio.
A meno che non mi manchi qualcosa, non è la differenza principale tra JNA vs JNI che con JNA non puoi chiamare il codice Java dal codice nativo (C)?
Nella mia specifica applicazione, JNI si è rivelato molto più facile da usare. Avevo bisogno di leggere e scrivere flussi continui da e verso una porta seriale e nient'altro. Piuttosto che provare a imparare l'infrastruttura molto coinvolta in JNA, ho trovato molto più facile prototipare l'interfaccia nativa in Windows con una DLL speciale che esportava solo sei funzioni: