A gdyby tak JNI bez JNI? ;-)

Kilka dni temu bawiłem się trochę JNI [Java Native Interface], technologia ogólnie dość miła i do zrealizowania nawet w Delphi.Dziś za to w pracy przyszedł mi do głowy problem ;-)W C# czy ogólnie .NET chcąc wykorzystać kod natywny wystarczy, że mamy bibliotekę DLL, która eksportuje odpowiednie funkcje i wszystko gra i buczy.W Java'ie dla JNI konieczne jest by DLLka eksportowała odpowiednio nazwane funkcje [w nazwie muszą mieć np. nazwę klasy która będzie ich używać]. Ogólnie jest to dość mocno "skodyfikowane".Zacząłem się więc zastanawiać czy można by było zbudować taki wrapper by dobrać się do dowolnej DLLki tak jak w .NET.Pomysł wydaje się do zrealizowania.Ogólna idea jest taka: mamy DLLkę która ma pewne funkcje które nas interesują. Mamy też w Java'ie klase o nazwie np. DLLWrapper. W konstruktorze przekazyujemy nazwę DLLki, tutaj natywny kawałek innej biblioteki DLL która jest zgodna z JNI ładuje naszą bibliotekę...Głębsza inwestygacja problemu wskazuje jednak, że nie obejdzie się tutaj bez wstawki w asemblerze.Jeżeli jeszcze pobranie adresu funkcji w WinAPI nie stanowi problemu [używamy do tego GetProcAddress] to chyba dynamiczne przekazanie parametrów jest możliwe tylko przez oprogramowanie sobie tego samemu w asemblerze :-(Choć z niekrytą złośliwą radością mogę wysnuć przypuszczenie, że po stronie Java'y będzie prościej ;-) bo teoretycznie wystarczy przekazać do wrappera nazwę funkcji w DLL, oraz nazwę metody w Java'ie która woła tą funkcje z DLL i listę parametrów np. w tablicy Object'ów.Resztę załatwić mogą odbicia.Problem ciekawy i zaczynam mu się przyglądać, a nuż coś wypłodzę ;-)


Podobne posty^beta
No czemu? Czemu .NETowa DLLka to nie DLLka? ;-)
C# miewa swoje plusy ;-)
JNA, czyli w Java'ie też można :-)
JNI i łańcuchy ;-)
Lądowanie Perseverance pokazuje, że komputery są potężne ;-)