21.5 Erweiterte JNI-Eigenschaften

Im letzten Beispiel haben wir auf der Java-Seite wenig unternommen beziehungsweise 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.

21.5.1 Klassendefinitionen

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 18, »Reflection und Annotationen«:

Class clazz = o.getClass();

Ähnlich funktioniert das in JNI. Dort benutzen wir die JNI-Funktion GetObjectClass():

jclass jclass;   // Zuweisung mit Initialisierung in klassischem C nicht möglich
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() bietet, so ermöglicht JNI Ähnliches mit FindClass().

jclass = (*env)->FindClass( env, "Klassenname" );

native void foo( C c );

JNIEXPORT jobject JNICALL foo( JNIEnv *env, jobject in_c )

jclass jclass = (*env)->GetObjectClass( env, in_c );

21.5.2 Zugriff auf Attribute

Um unter Reflection auf die Attribute zuzugreifen, muss das Class-Objekt ein Field-Objekt akquirieren:

Field field = clazz.getField( Feldname );

Ähnlich funktioniert auch dieses wieder in JNI. Mit der JNI-Funktion GetFieldID() erhalten wir einen Zeiger auf den Speicherplatz eines Felds.

class C { int i; }

Um die Attribut-ID zu erlangen, schreiben wir:

jfieldID jfid;
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 einen Integer, und die anderen Typen haben wir schon einmal beleuchtet. Zur Wiederholung:

Der letzte Schritt ist das Auslesen beziehungsweise Setzen der Werte. Wiederum soll uns Reflection eine Orientierung geben:

Class clazz = o.getClass();
Field field = clazz.getField( Feldname );
field.setAttribute( o, new Integer(9) );

jfieldID jfid;
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. Die Tabelle fasst sie zusammen:

Die entsprechenden SetXXXField()-Funktionen lassen sich leicht ableiten. Die letzte Frage ist die nach den Datentypen. Die anschließende Tabelle zeigt, welcher Java-Typ welchem nativen Typ zugeordnet ist und wie die Wertebereiche sind:

21.5.3 Methoden 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.

id = (*env) -> GetMethodID( env, cls, "getAbsolutePath", "()Ljava/lang/String;" );
if ( id == 0 ) { /* Fehlerbehandlung */ }

$ javap -s java.io.File

public class java.io.File extends java.lang.Object implements java.io.Serializable,java.lang.Comparable{
 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.

id = (*env) -> GetMethodID( env, cls, "getAbsolutePath", "()Ljava/lang/String;" );
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 CallStaticVoidMethod().

In unserem Beispiel mit getAbsolutePath() vom File-Ojekt hat die Methode keinen Parameter. Die C-Methoden Call<Typ>Method() bzw. CallStatic<Typ>Method() sind so definiert, dass sie Argumente per Varargs annehmen:

Call<type>Method( JNIEnv *env, jclass clazz, jmethodID methodID, ... );
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" beziehungsweise 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.

21.5.4 Threads 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.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.