2011-02-10 15 views
5


Ho iniziato a esaminare JNI e da quello che ho capito è che se si verifica un problema con la DLL caricata, jvm è possibile terminare sul posto.
I.e. il processo non può essere protetto, ad es. come quando si cattura un'eccezione.
Quindi, se la mia comprensione è corretta, la mia domanda è se esiste un approccio/modello standard per questa situazione quando si utilizza jni.
O per dirlo in modo diverso, i processi che utilizzano jni sono progettati in modo da evitare questi problemi? Non ci si aspetta che tali problemi si verifichino?jni starter question

Grazie.

risposta

3

Sì, la JVM terminerà solo una delle ragioni per cui il codice JNI è davvero difficile da eseguire il debug. Se si utilizza il codice C++, è possibile utilizzare eccezioni e quindi associarle a un'eccezione Java che fornisce almeno un certo livello di sicurezza ma non aiuta con problemi come l'accesso alla memoria errato.

Da un punto di vista dell'architettura Suggerisco di separare il codice da JNI il più possibile. Crea una struttura di classe/procedura interamente testabile da C++/C e lascia che il codice JNI esegua solo tutte le conversioni. Se la JVM si blocca, almeno sai dove devi guardare.

+0

La prima idea che stavo pensando è stata la collocazione del post, stava generando un nuovo processo per accedere alla dll. In questo modo il processo originale sopravvive.Ma non sono sicuro se questo viene usato come un apploach – Cratylus

+0

Hm, ma in tal caso si potrebbe anche non utilizzare affatto JNI e passare a un altro modo di comunicazione tra processi. Userei solo JNI se la velocità è il problema più grande (e quindi non ha senso inserirlo nel suo stesso processo). È un commercio tra velocità e sicurezza. – Daff

1

I principi non sono diversi da qualsiasi applicazione multi-threaded C:

  1. Controllare sempre tutti i vostri input accuratamente.
  2. Liberare sempre la memoria temporanea assegnata.
  3. Assicurati che le tue funzioni siano rientranti.
  4. Non fare affidamento su un comportamento non definito.

La Java virtual machine non offre alcuna protezione aggiuntiva per il codice nativo, in caso di errori o perdite, la VM non riuscirà o perde.

+0

@Daff: La prima idea che stavo pensando era posizionare il post, stava generando un nuovo processo per accedere alla dll. In questo modo sopravvive il processo originale. Ma non sono sicuro se questo viene usato come un appunto – Cratylus

+0

@ user384706 Generare un nuovo processo non è esente da rischi ed è inaccettabilmente lento per la maggior parte degli usi. Inoltre, se stai avviando comunque un processo esterno, perché non farlo da Java puro? – biziclop

+0

L'idea che stavo pensando che il codice nativo sarebbe stato usato in casi specifici che non potevano essere fatti in java, il processo originale genera un nuovo processo per accedere alla DLL e qualsiasi risultato/messaggio verrebbe inviato al processo genitore. Se succede qualcosa, il secondo processo muore ma il processo originale che potrebbe fare molto più funzionalità (accedere a una DLL) è solo una parte, sarebbe ancora in vita. Non sono sicuro se questo è un approccio utilizzato. Potrebbe essere troppo? – Cratylus

0

È possibile avere esattamente lo stesso spettro di gestione degli errori in una libreria JNI come in qualsiasi altra cosa.

È possibile utilizzare try/catch. Se sei su Windows, puoi usare SEH. Se sei su Linux, puoi chiamare sigaction.

Tuttavia, se si incasina e c'è un SIGSEGV, probabilmente la tua JVM tosta se provi a rilevare quel segnale oppure no.