Java Native Interface (JNI) är en standardmekanism för att köra kod under kontroll av Java Virtual Machine (JVM), som är skriven i C/C++ eller Assembly och länkad som dynamiska bibliotek; tillåter att inte använda statisk länkning. Detta gör det möjligt att anropa en C / C++- funktion från ett Java -program och vice versa. Tidigare gränssnitt, till skillnad från JNI, uppfyllde inte villkoret för binär kompatibilitet .
Den största fördelen med JNI jämfört med den tidigare versionen ( JDK 1.0 NMI - Native Method Invocation) och andra liknande gränssnitt (Netscape Java Runtime Interface eller Microsofts Raw Native Interface och COM/Java Interface) är att JNI ursprungligen designades för binär kompatibilitet , för tillämpning kompatibilitet, skriven med JNI, för alla virtuella Java-maskiner på en specifik plattform. Därför måste kompilerad C / C++- kod exekveras av Java-maskiner, till exempel i olika webbläsare, utvecklingsverktyg som Symantec Visual Cafe och Sun Java Workshop, för en viss plattform ( Win32 i det här fallet). Tidigare gränssnitt uppfyllde inte det binära kompatibilitetsvillkoret .
Genom denna mekanism kan Java-bytekod interagera med system- eller applikationsplattformsspecifik kod som körs direkt under olika operativsystem [1] .
Det plattformsspecifika JNI-gränssnittet ger inte åtkomst till hela applikationsprogrammeringsgränssnittet för ett visst operativsystem, utan bara till en del av det. JNI användes först i Java version 1.1 och utvecklades i Java 2.
NMI (Native Method Invocation) var den första mekanismen Sun specificerade för att anropa C-kod från Java, och den enda mekanismen som stöds i JDK 1.0.2. I alla efterföljande versioner av Java stöds inte längre NMI , eftersom det ersätts av en delvis kompatibel JNI-mekanism.