Łączenie środowiska wykonawczego JNI

Interfejs JNI (Java™ Native Interface) umożliwia łączenie środowisk wykonawczych z bibliotekami rodzimymi dynamicznymi i statycznymi.

Informacje specyficzne dla systemów z/OS®

Jeśli łączenie w czasie wykonywania powoduje konflikt symboli, aplikacja musi rozwiązać konflikt, zmieniając nazwę symbolu po stronie aplikacji lub wyłączając łączenie w środowisku wykonawczym.

Dynamiczne łączenie w systemie z/OS

Podczas budowania programu w języku C lub C + +, który korzysta z interfejsu API JNI Invocation w celu utworzenia wirtualnej maszyny języka Java i wywołuje kod Java, należy użyć opcji -L w celu wykonania następujących zadań:

  • Dodaj /usr/lib i /lib do listy katalogów, w których wyszukiwane są obiekty współużytkowane. Wszystkie programy wymagają współużytkowanych obiektów, które są przechowywane w tych katalogach.
  • Dodaj katalogi Java java_install_dir/lib i java_install_dir/lib/j9vm do listy katalogów, w których wyszukiwane są obiekty współużytkowane. Te katalogi zawierają współużytkowane biblioteki Java. Użytkownik chce również połączyć się z programem libjvm.so (za pomocą opcji -ljvm ).

Na przykład ten kod buduje program uruchamiający API wywołania o nazwieinvAPITest , kompilując program C invAPITest.c:

cc [-q32|-q64] -Ijava_install_dir/include 
	-o invAPITest 
	-L/usr/lib 
	-L/lib 
	-Ljava_install_dir/lib/j9vm 
	-Ljava_install_dir/lib 
	-ljvm invAPITest.c

Wartość -q32 lub -q64 określa model danych, w którym budowany jest program. Jeśli te wartości zostaną pominięte, zostanie użyty domyślny model danych.

Gdy uruchamiany jest program w języku C lub C + +, który używa interfejsu API JNI Invocation do uruchamiania klas Java, należy upewnić się, że ścieżka klasy jest poprawnie skonfigurowana, aby umożliwić maszynie JVM znalezienie plików klas. W przypadku modyfikacji ścieżki klasy startowej Java należy dołączyć pliki pakietu SDK, które są niezbędne do uruchomienia aplikacji.

Aby upewnić się, że biblioteka JNI eksportuje funkcje, które musi być rozstrzygane przez aplikację Java w czasie wykonywania, można sprawdzić bibliotekę przy użyciu narzędzia nm . Na przykład biblioteka JNI o nazwie libjnitest.so, która zawiera podprogramy JNI fooImpl i barImpl, musi wyeksportować następujące symbole:

$nm libjnitest.so
     255552 T Java_mypackage_SampleClass_fooImpl
     255528 T Java_mypackage_SampleClass_barImpl

Więcej informacji na ten temat zawiera sekcja Wartości domyślne opcji Kompilatora.

Metody rodzime można zapisywać w następujący sposób:
Biblioteki połączeń dynamicznych
W systemach IBM Z® metody JNI są zwykle przechowywane w bibliotekach dynamicznych o nazwie Dynamic Link Libraries (DLLs). Biblioteki DLL zawierają funkcje i dane, które mogą być przywoływane z innego modułu ładowalnego, na przykład biblioteki dynamicznej lub programu wykonywalnego. Metody rodzime są przechowywane w listach DLL i są połączone w czasie budowania, przez proces łączenia lub w czasie wykonywania, dynamicznie ładując metody przy użyciu interfejsu API IBM Z dllload lub interfejsu API zgodnego z POSIX dlopen. Więcej informacji na temat funkcji dllload () i dlopen () zawiera sekcja Ładowanie biblioteki DLL.

Programy mogą również dynamicznie łączyć się ze współużytkowanymi bibliotekami i obiektami współużytkowanymi, na przykład za pomocą rodzin dlopen() lub dllload() podprogramów. Odsyłacze JVM w ten sposób są używane podczas ładowania rodzimych bibliotek (na przykład: System.load(), System.loadLibrary(), Runtime.getRuntime().load(), Runtime.getRuntime().loadLibrary()).

Więcej informacji na temat tych podprogramów można znaleźć w sekcji dlopen () i dllload ().

Uwaga: Aby zapewnić pomyślne utworzenie dynamicznego łączenia bibliotek rodzimych, można opcjonalnie zaimplementować funkcje cyklu życia JNI_Onload() i JNI_OnUnload() w bibliotece. Jeśli zaimplementowano produkt JNI_Onload(), biblioteka rodzima musi wyeksportować ją w inny sposób, ponieważ nie jest ona widoczna dla środowiska wykonawczego, a maszyna JVM zakłada, że biblioteka wymaga tylko wersji JNI JNI_VERSION_1.1. Jeśli produkt JNI_OnUnload() został zaimplementowany, musi być również wyeksportowany. Jeśli produkt JNI_Onload() jest implementowany i eksportowany, zwracana jest najnowsza wersja JNI, na przykład JNI_VERSION_1.8.

Łączenie statyczne w systemie z/OS

Istnieje możliwość statycznego połączenia z bibliotekami JNI, oprócz dynamicznego łączenia. Biblioteki statyczne mogą być łączone na obraz niestandardowego programu uruchamiającego, który uruchamia proces maszyny JVM przy użyciu interfejsów API wywołania.

Rozważ dwie biblioteki statyczne: testlibA i testlibB. W przypadku próby załadowania biblioteki testlibA w programie Java za pomocą komendy, takiej jak System.loadLibrary("testlibA"), maszyna JVM po raz pierwszy wgląda się w obraz uruchamianego programu wykonywalnego dla procedury o nazwie JNI_OnLoad_testlibA(). Jeśli ta procedura zostanie znaleziona, maszyna JVM użyje tej statycznie powiązanej biblioteki w celu udostępnienia definicji JNI. Jeśli procedura nie zostanie znaleziona, maszyna JVM będzie dynamicznie ładować bibliotekę testlibA (na przykład libtestlibA.so), przeglądając ścieżki określone przez produkt -Djava.library.path (lub LIBPATH).

W systemach IBM Z należy określić następujące opcje podczas budowania:
  • Wc,DLL, aby upewnić się, że program wykonywalny jest budowany jako biblioteka DLL.
  • Wc,EXPORTALL, aby upewnić się, że symbole w programie wykonywalnym są eksportowane i udostępniane do wyszukiwania przez współużytkowane biblioteki, które są ładowane przez program.
Te opcje umożliwiają programowi wykonywalnemu programu uruchamiającego eksportowanie symboli (takich jak JNI_Onload_testlibA()), dzięki czemu maszyna JVM może je wyszukać przed próbą połączenia dynamicznego.
W poniższym przykładzie użyto linii kompilacji i linii łączników, aby upewnić się, że biblioteki statyczne testlibA i testlibB są połączone z programem uruchamiającym, który został zbudowany jako biblioteka DLL, i eksportuje wszystkie symbole.
cc -c -Wc,DLL,EXPORTALL launcher.c -o launcher.o
cc testlibA.o testlibB.o launcher.o -o launcher

Alternatywnie można usunąć program EXPORTALL, w którym to przypadku program eksportuje konkretne symbole za pomocą programu #pragma export. Więcej informacji na ten temat zawiera sekcja Eksport#pragma.

Uwaga: W systemach IBM Z program wykonywalny musi być zbudowany jako biblioteka DLL (Dynamic Link Library) oprócz symboli eksportu, jeśli program wykonywalny będzie pakował procedury JNI, do których musi się odwoływać program Java, za pomocą łącz statycznych. Jeśli program wykonywalny IBM Z definiuje i eksportuje JNI_OnLoad_testlibA, ale nie jest on sam zbudowany jako biblioteka DLL (to znaczy, że -Wc,DLL nie jest określony), łączenie statyczne prawdopodobnie nie powiedzie się, ponieważ środowisko wykonawcze nie może usunąć symbolu z powrotem z programu wykonywalnego.

Procedura inicjowania biblioteki JNI_OnLoad_L, dla biblioteki L, musi zwracać wartośćJNI_VERSION_1_8(0x00010008).