Portál AbcLinuxu, 20. května 2024 12:02
V našem seriálu nám doposud scházela jedna důležitá věc. Naučili jsme se, jak může Java volat nativní kód. Teď je ale na čase jí to oplatit a zavolat nazpět. Dále se podíváme na přistupování ke členským proměnným a na práci s poli.
Spousta seriálů a návodů začíná ukázkou „Hello world“. Tento článek sice není prvním dílem, ale přesto jej také zahájíme Hello world, byť dosti neobvyklým. Následující kód je sice jako škrábat se levou rukou na pravém uchu, ale jako ukázka možností poslouží.
void helloWorld(JNIEnv* env)
{
jclass clsSystem = env->FindClass("java/lang/System");
jfieldID fOut = env->GetStaticFieldID(clsSystem, "out", "Ljava/io/PrintStream;");
jobject out = env->GetStaticObjectField(clsSystem, fOut);
jmethodID mPrintln = env->GetMethodID(env->GetObjectClass(out), "println", "(Ljava/lang/String;)V");
env->CallVoidMethod(out, mPrintln, "Hello world!");
}
Po chvilce zděšení[*] jste asi všichni dospěli ke správému úsudku, že tento kód odpovídá jednoduchému volání System.out.println("Hello world"), akorát za použití reflexe v JNI. Jen pro zajímavost si ukážeme, jak toto volání vypadá v bajtkódu Javy:
Ale vždyť je to přece krásné! Proč jenom ještě někdo nenapsal převodník Javy do C/JNI?
0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream; 3: ldc #3; //String Hello world 5: invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
Aby nebylo nutné opakovaně vyhledávat metody a pole (členské proměnné) podle jejich názvů a signatury, existují v JNI typy jmethodID a jfieldID, které danou metodu nebo proměnnou popisují. V případě těchto typů se nemusíme starat o uvolňování paměti. Při vytváření signatur (popisu typů) se řídíme tabulkou, která je k vidění v druhém díle seriálu, u metod pak ještě odkáži na odstavec o signaturách metod v jiném z minulých dílů.
Abychom si to shrnuli, tak signatury se mezi proměnnými a metodami liší následovně:
Další důležitou věcí je vědět, zda pole nebo metoda je, nebo není, statická. Podívejme se tedy na funkce pro získávání identifikátorů polí:
Jedinou praktickou odlišností je tedy název funkce, toť vše. U metod to není jiné:
Při získávání a nastavování hodnot opět rozlišujeme mezi statickými a nestatickými členy. Pro každý z těchto druhů existuje skupina devíti funkcí, které se odlišují datovým typem pole. Ten tedy zohledňujeme nejen v signatuře, ale při nastavování/získávání hodnoty i v názvu volané funkce. Obecná podoba funkcí je následující:
Součást názvu Typ může nabývat hodnot Boolean, Byte, Char, Short, Int, Long, Float, Double – dosti tedy kopíruje názvy boxovaných typů. Typ T už je intuitivní, nicméně přehled najdete v druhém článku. Pro úplnost připomenu, že pole je také objekt. No a při získávání hodnoty členské proměnné to bude zase naruby, tj. T nebude jako poslední argument funkce, ale jako návratový typ:
Funkcí pro volání metod je zase celá velká sada. Máme možnost volat statické metody (T CallStaticTypMethod(...)) a nestatické metody (T CallTypMethod(...)). Jako Typ lze u metod kromě devíti výše uvedených typů použít i Void. Jsou tu ale ještě další speciality: můžeme volat nestatickou metodu s určením třídy, nebude se tedy brát v potaz tabulka virtuálních funkcí (T CallNonvirtualTypMethod(...). A konečně pak ještě máme tři různé způsoby, jak předávat argumenty. Jestli správně počítám, dává to celkem 90 funkcí, mezi kterými si musíme správně vybrat.
První způsob, jak předat argumenty, je předveden v ukázce na začátku článku. V tomto případě se použitá funkce JNI nazývá například CallVoidMethod a má variabilní počet argumentů:
void CallVoidMethod(jobject obj, jmethodID methodId, ...)
Logicky musíme předat správný počet argumentů! Jako poslední argument není potřeba dávat NULL (jako u execl()), protože podle ID metody je jasné, kolik argumentů byste měli předávat. Druhý způsob je dodat argumenty přes va_list – osobně mi to nepřijde moc užitečné, takže vás v této věci odkáži na manuálovou stránku STDARG(3).
void CallVoidMethodV(jobject obj, jmethodID methodId, va_list args)
A třetím způsobem, u kterého se na chvíli zastavíme, je předat pole hodnot typu jvalue:
void CallVoidMethodA(jobject obj, jmethodID methodId, jvalue* args)
jvalue má oproti va_list tu zásadní výhodu, že se dá velmi snadno dynamicky vytvářet. jvalue je definováno jako union:
typedef union jvalue {
jboolean z;
jbyte b;
jchar c;
jshort s;
jint i;
jlong j;
jfloat f;
jdouble d;
jobject l;
} jvalue;
Užití jvalue si dovedu představit v různých wrapperech. Pro ukázku nám postačí něco snazšího, i když bychom se v tomto případě bez jvalue obešli. Zavoláme si známou metodu Integer.parseInt(String s, int radix):
jstring strBinary = env->NewStringUTF("1011010111");
jclass clsInteger = env->FindClass("java/lang/Integer");
jmethodId mParseInt = env->GetStaticMethodID(clsInteger, "parseInt", "(Ljava/lang/String;I)I");
jvalue args[2];
args[0].l = strBinary;
args[1].i = 2;
int result = env->CallStaticMethodA(clsInteger, mParseInt, args);
// v proměnné "result" bude 727
Ještě si ukážeme volání metody bez použití tabulky virtuálních funkcí. Nenapadá mě, jak přesně to samé udělat v Javě. Jen volání super.metoda() se tomuto přibližuje, i když v tomto případě si nemůžeme vybírat, jakou konkrétní třídu chceme použít. Ale nuže dobrá, předvedeme si obdobu super.metoda():
void metoda(JNIEnv* env, jobject jThis)
{
// Získáme obdobu "super"
jclass superClass = env->GetSuperclass(env->GetObjectClass(jThis));
// Získáme ID aktuální metody
jmethodID mMetoda = env->GetMethodID(superClass, "metoda", "()V");
// Zavoláme
env->CallNonvirtualVoidMethod(jThis, superClass, mMetoda);
}
A jak jste jistě správně pochopili, funkce CallNonvirtualVoidMethod je deklarována následovně:
void CallNonvirtualVoidMethod(jobject obj, jclass clazz, jmethodID methodId, ...)
Práce s poli sice se zbytkem této lekce zdánlivě nesouvisí, ale má s ním něco společného. I pro práci s poli je spousta funkcí, které se liší používaným datovým typem. První funkcí je GetArrayLength(), které funguje u všech polí, odpovídá .length v Javě a funguje následovně:
int printLength(JNIEnv* env, jarray arr)
{
jsize len = env->GetArrayLength(arr);
std::cout << "Velikost pole je " << len << std::endl;
}
Pole primitivního typu vytvoříme pomocí jedné z funkcí void NewTypArray(jsize length). Pole objektů je trochu jiné, zde určujeme typ a počáteční hodnotu prvků:
void vytvorPole(JNIEnv* env, int length)
{
jclass cls = env->FindClass("java/lang/String");
jstring str = env->NewStringUTF("Ahoj");
jarray arr = env->NewObjectArray(length, cls, str);
env->SetObjectArrayElement(arr, 0, env->NewStringUTF("Čau!"));
}
Asi není třeba nic dodávat. U primitivních typů je to složitější, a to zejména díky tomu, že máme možnost do nich zapisovat nebo je číst efektivněji než položku po položce. Hlavní funkcí, která nám zpřístipní celé pole je tato:
T* GetTypArrayElements(jarray array, jboolean* isCopy)
Poslední argument můžeme nastavit na NULL. Je to jen informace pro nás, jestli JNI/JVM muselo vytvářet pro naše použití kopii pole. Pokud dostaneme odpověď JNI_FALSE, tak přímo zapisujeme do paměti javovského programu. V opačném případě se obsah nakopíruje zpět až po zavolání této funkce – a vězte, že je nutné ji zavolat vždy, bez ohledu na hodnotu isCopy:
void ReleaseTypElements(jarray array, T* data, jint mode)
mode je zajímavá hračka. Pokud zadáme 0, tak se data přenesou zpět do javovského programu a naše práce je u konce. Pokud jsme nic neměnili, můžeme použít konstantu JNI_ABORT, takže se vyvarujeme případnému kopírování položek, kdyby náhodou isCopy bylo JNI_TRUE. A poslední možností je JNI_COMMIT, kdy jsou data přenesena zpět do javovského programu (v ten moment máme záruku, že je program vidí), ale dáváme vědět, že s nimi ještě budeme pracovat – tedy že budeme Release volat ještě minimálně jednou.
void vytvorPolePlneNul(JNIEnv* env)
{
// Vytvoříme pole
jarray arr = env->NewIntArray(10);
// Získáme céčkový ukazatel na pole
jint* pArr = env->GetIntArrayElements(arr, 0);
// Nastavíme hodnotu na nuly
memset(pArr, 0, sizeof(jint)*10);
// Vrátíme pole Javě
env->ReleaseIntArrayElements(arr, pArr, 0);
}
Pokud z výkonnostních důvodů potřebujeme zvýšit šanci, že data nejsou mezi nativním a javovským programem kopírována, můžeme použít funkce GetPrimitiveArrayCritical a ReleasePrimitiveArrayCritical (tentokrát bez určení typu). Ještě než tak uděláte je ale vhodné přečíst si důkladně popis v dokumentaci, protože jsou zde takto omezení na to, co si nativní program může při své práci nad polem dovolit dělat.
Na závěr zmiňme ještě dvojici GetTypArrayRegion a SetTypArrayRegion. Při jejich použití nemusíme získávat přístup k celému poli, nýbrž jen k jeho části.
Příště se podíváme ještě na nějaké zbývající drobnosti. Pak už přijde řada na JNA.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.