22.5Erweiterte JNI-Eigenschaften 
Im letzten Beispiel haben wir auf der Java-Seite wenig unternommen bzw. lediglich eine C-Funktion aufgerufen und ein Ergebnis zurückgegeben. Nun wollen wir Objekteigenschaften auslesen, Methoden aufrufen und Objekte erzeugen. JNI bietet noch mehr als nur die Übergabe von primitiven Datentypen und Strings.
22.5.1Klassendefinitionen
JNI repräsentiert ein Java-Objekt durch jobject. Um auf Attribute eines Java-Objekts zuzugreifen, müssen wir zunächst die Klassendefinition erfragen. Wir kennen das bereits aus Kapitel 17, »Typen, Reflection und Annotationen«:
Ähnlich funktioniert das in JNI. Dort benutzen wir die JNI-Funktion GetObjectClass(…):
jclass = (*env)->GetObjectClass( env, obj );
obj repräsentiert das Objekt, für das wir die Klassendefinition besorgen.
Und wie auch Reflection nicht nur mit getClass() das Class-Objekt liefert, sondern auch eine Suche nach dem Klassenamen mit Class.forName(String) bietet, so ermöglicht JNI Ähnliches mit FindClass(…):
[zB]Beispiel
Ein Exemplar der Klasse C wird einer nativen Funktion übergeben. Die Deklaration der nativen Methode in Java ist folgende:
Die Übersetzung liefert uns in etwa:
Es holt GetObjectClass(…) die Klassendefinition, die anschließend in jclass steht:
22.5.2Zugriff auf Attribute
Um unter Reflection auf die Attribute zuzugreifen, muss das Class-Objekt ein Field-Objekt akquirieren:
Ähnlich funktioniert auch dieses wieder in JNI. Mit der JNI-Funktion GetFieldID(…) erhalten wir einen Zeiger auf den Speicherplatz eines Feldes.
[zB]Beispiel
Jetzt müssen wir nur über unsere Klasse C weitere Aussagen machen. Geben wir Folgendes vor:
Um die Attribut-ID zu erlangen, schreiben wir:
jfid = (*env)->GetFieldID( env, jclass, "i", "I");
Den zweiten Parameter entlarven wir als Zeiger auf die Klassendefinition. Das dritte Argument kennzeichnet den Namen der Variablen (i in der Klasse C), und das letzte Argument bestimmt den Typ der Variablen. Das große I kennzeichnet ein Integer, und die anderen Typen haben wir schon einmal beleuchtet. Zur Wiederholung:
Signatur | Typ |
|---|---|
Z | boolean |
B | Byte |
C | Char |
S | Short |
I | Int |
J | Long |
F | Float |
D | Double |
V | Void |
LvollQualifizierterName; | Objekttyp |
[Typ | Feld mit Typ |
Tabelle 22.1Kodierung von Typen
Der letzte Schritt ist das Auslesen bzw. Setzen der Werte. Wiederum soll uns Reflection eine Orientierung geben:
Field field = clazz.getField( Feldname );
field.setAttribute( o, new Integer(9) );
[zB]Beispiel
Die JNI-Funktion GetIntField(…) liest das Attribut des Objekts aus:
jclass jclass;
jint val;
jclass = (*env)->GetObjectClass( env, in_c );
jfid = (*env)->GetFieldID( env, jclass, "i", "I");
val = (*env)->GetIntField( env, in_c, jfid );
Für die unterschiedlichen Typen stehen ebenfalls ganz unterschiedliche GetXXXField(…)-Funktionen zur Verfügung. Tabelle 22.2 fasst sie zusammen:
GetField | Nativer Typ | Java-Typ |
|---|---|---|
GetObjectField(…) | jobject | Object |
GetBooleanField(…) | jboolean | boolean |
GetByteField(…) | Jbyte | Byte |
GetCharField(…) | Jchar | char |
GetShortField(…) | Jshort | short |
GetIntField(…) | Jint | int |
GetLongField(…) | Jlong | long |
GetFloatField(…) | Jfloat | float |
GetDoubleField(…) | jdouble | double |
Tabelle 22.2Zugriff auf Attribute von Java-Objekten
Die entsprechenden SetXXXField(…)-Funktionen lassen sich leicht ableiten. Die letzte Frage ist die nach den Datentypen. Tabelle 22.3 zeigt, welcher Java-Typ welchem nativen Typ zugeordnet ist und wie die Wertebereiche sind:
Java-Typ | Nativer Typ | Beschreibung |
|---|---|---|
boolean | jboolean | 8 Bit ohne Vorzeichen |
byte | jbyte | 8 Bit mit Vorzeichen |
char | jchar | 16 Bit ohne Vorzeichen |
short | jshort | 16 Bit mit Vorzeichen |
int | jint | 32 Bit mit Vorzeichen |
long | jlong | 64 Bit mit Vorzeichen |
float | jfloat | 32 Bit |
double | jdouble | 64 Bit |
void | void |
Tabelle 22.3Mapping zwischen Javas primitiven Datentypen (sowie void) und C
22.5.3Methoden aufrufen
So wie bei Attributzugriffen eine jfieldID nötig ist, so bedarf es bei Methodenaufrufen einer jmethodID. Diese liefert die Methode GetMethodID(…) für Objektfunktionen und GetStaticMethodID(…) für statische Funktionen. Anzugeben bei der ID-Suche ist der Name der Funktion und als String kodiert der Rückgabetyp und die Parametertypen. Ist das Ergebnis des Methodenaufrufs 0, so gibt es die Methode nicht:
if ( id == 0 ) { /* Fehlerbehandlung */ }
[»]Hinweis
Für die nicht so intuitive String-Signatur der Methode bietet sich das Dienstprogramm javap mit dem Schalter -s an:
Der relevante Ausschnitt in unserem Fall lautet:
public java.lang.String getAbsolutePath();
Signature: ()Ljava/lang/String;
}
Die Funktionen CallObjectMethod(…) bzw. CallStaticMethod(…) rufen mit der jmethodID die Java-Funktion auf. Sie sind für alle Funktionen gedacht, die ein Objekt (also auch Felder) zum Ergebnis haben:
obj = (*env)->CallObjectMethod( env, file, id );
Ist das Ergebnis ein primitiver Typ, steht der Typ der Rückgabe im Funktionsnamen – der Bauplan für die Namen ist CallTypMethod(…) bzw. CallStaticTypMethod(…), also etwa CallBooleanMethod(…). Im Fall keiner Rückgabe steht für den Typ einfach Void wie in CallStaticVoidMethod(…).
In unserem Beispiel mit getAbsolutePath() vom File-Objekt hat die Methode keinen Parameter. Die C-Methoden Call<Typ>Method(…) bzw. CallStatic<Typ>Method(…) sind so definiert, dass sie Argumente per Varargs annehmen:
CallStatic<type>Method( JNIEnv *env, jclass clazz, jmethodID methodID, ... );
Neben den mit … definierten Varargs gibt es zwei weitere Varianten für alle Funktionen, die auf »A« bzw. auf »V« enden:
CallStatic<Typ>MethodA(JNIEnv *env, jclass clazz, jmethodID methodID, jvalue *args);
Call<Typ>MethodA(JNIEnv *env, jclass clazz, jmethodID methodID, jvalue *args);
CallStatic<Typ>MethodV(JNIEnv *env, jclass clazz, jmethodID methodID, va_list args);
CallObject<Typ>MethodV(JNIEnv *env, jclass clazz, jmethodID methodID, va_list args);
Die Funktionen mit der Endung »A« nehmen die Argumente für die Java-Funktion über einen Verweis auf ein jvalue-Feld an, und die Methode mit der Endung »V« nimmt die Argumente in einer Struktur vom Typ va_list an.
22.5.4Threads und Synchronisation
Die Struktur JNIEnv bietet zur Synchronisation die zwei Funktionen, um das Betreten und Verlassen eines synchronisierten Blocks nachzubilden:
jint MonitorEnter(JNIEnv *env, jobject obj);
jint MonitorExit(JNIEnv *env, jobject obj);
Das zweite Argument ist genau das Lock-Objekt, an dem synchronisiert wird. Während in purem Java die Laufzeitumgebung bei einer Exception den Lock wieder freigibt, müssten wir das in C selbst überwachen.
22.5.5@Native Markierungen *
Zwischen Java-Programmen und nativen Programmen gibt es oft eine Wechselwirkung in der Form, dass Java-Programme native Funktionen aufrufen und diese wiederum Java-Methoden aufrufen oder auf Variablen zugreifen. Für den Fall, dass native Methoden auf Java-Konstanten zugreifen, gibt es in Java 8 eine Annotation java.lang.annotation.Native, die genau diese Konstanten markiert. Auf diese Weise kann ein Generatorwerkzeug diese Java-Konstanten in native Header-Dateien kopieren, sodass für den Konstantenzugriff kein JNI-Aufruf nötig ist, sondern die Konstante aus der Header-Datei genommen werden kann. @Native hat den Retention-Typ SOURCE, ist also nur für Tools sichtbar, die auf der Codeebene arbeiten, etwa javac.
