Java Native Interface: propojujeme Javu a C/C++ – 1 (diskuse)

[Martin Beránek]

Díky. Pěkné. Zatím jsem JNI nikdy k ničemu nepotřeboval, ale to se může změnit. Přestože toto je na Linux zaměřený server, nebyl by nějaký příklad cross-compilace i pro windows?

[Luboš Doležel (Doli)]

To už je hodně dlouho, co jsem dělal crosscompilaci. Na Gentoo šlo crosscompilátor hezky zkompilovat a pak používat, na Debianu nevím, ale nějaký mingw tu je.

[Sid]

Myslim, ze pre bezne veci je urcite lepsie pouzit JNA ktore zapuzdruje JNI.

[vyzivus]

Vdaka za clanok, ale tiez odporucam JNA - nie je nutne robit ziadne zmeny do C kniznice (pridavat JNIEXPORT apod), krasne podporuje struct, pstruct a dalsie veci. Viac na https://jna.dev.java.net/

[Luboš Doležel (Doli)]

Na JNA dojde taky. JNI ukazuju hlavně kvůli použitelnosti v obou směrech (nativní kód z Javy i Java z nativního kódu).

[pepa_u]

Chapu to spravne, ze JNA umoznuje akorat volani native funkci, nicmene, potrebuji-li pouzit objekty z C++, pak se JNI a vlastnimu wrapperu nevyhnu?

[Honza]

To jsem zvědavý, co z toho seriálu vyleze. dělám v práci na Androidu, hodně i s NDK, takže JNI se dost zabývám. Taky už jsem se párkrát dost nachytal, třeba s nemazáním lokálních referencí v cyklu (padačka) nebo různé radosti s vlákny a neplatností JNIEnv *.

[Luboš Doležel (Doli)]

Reference jsou někdy pěkná pakárna, proto jsem si na vše, co tu budu popisovat, nakonec napsal wrapper. Dokud jsem si vše řádně neowrapoval, byl někdy pěkný boj najít důvod proč to padá nebo proč mám v rukou najednou úplně jiný objekt.

třeba s nemazáním lokálních referencí v cyklu (padačka)

To padalo kvůli překročení maximálního počtu referencí ve scope? Jinak si teď nedovedu představit, proč by to padalo.

[Honza]

Jojo, maximílní počet referencí. Na rozumně krátkých testovacích datech vše perfektně fungovalo. Ale pak si zákazník synchronizoval kontakty s facebookem a to už while cyklus přes kontakty s nemazáním lokální reference (přece ji to pak smaže samo, až se vrátim do javy, že...) neustál

[Honza]

Další moje oblíbená chybka je nevytvoření globální reference. Do se taky príma ladí...

[Luboš Doležel (Doli)]

To mi povídej...

Mrkni na můj wrapper. Ten všechny lokální reference rovnou ruší a místo nich si zakládá globální, o jejichž zrušení se pak stará destruktor třídy.

[arny]

Ja s JNI nemam velmi dobre skusenosti. Problem je hlavne v nemanageovanej a manageovanej pamati. Kazdy pad ci uz nativnej kniznice alebo JNI rozhrania, znamena pad celej aplikacie. Z tohto dovodu je dobre pouzivat zasadu, ze co najviac sa vyhybat nativnym knizniciam a ked ich uz musim pouzit tak izolovat izolovat a zasa izolovat a to najlepsie do separatneho procesu. Pri desktopovych aplikaciach to este nemusi byt velky problem, ale ked vam padne cely server, tak to potom zacina zabava. V podstate JNI dedi chyby po nativnej kniznici a pokial si ju este nevytvarate sami ale pouzivate nejaky tretostrannu kniznicu, tak mate o zabavu postarane.

[kralуk]

Z tohto dovodu je dobre pouzivat zasadu, ze co najviac sa vyhybat nativnym knizniciam a ked ich uz musim pouzit tak izolovat izolovat a zasa izolovat a to najlepsie do separatneho procesu.

Což má ale dopad na výkon, v některých případech může být i dost vysoký...

[arny]

Ano ma ale poznas ten vtip o pentiu, ked sa ho AMD pytalo kolko je 2+2 a ono odpovedalo, ze 5. AMD na to ze to nieje spravne ale pentium povedalo, ze je to rychle. Proste ked sa mas rozhodnut medzi rychlostou a stabilitou ja osobne volim stabilitu.

[kralуk]

Nějak mi není jasný, jak ti nenativita nějaké knihovny zaručuje její stabilitu?

K tomu vtipu: Nativní aplikace dokážou podávat výsledek nejen rychle, ale i správný

[arny]

Nezarucuje, ale podstatne ju zvysuje.

[Luboš Doležel (Doli)]

Pri desktopovych aplikaciach to este nemusi byt velky problem, ale ked vam padne cely server, tak to potom zacina zabava.

Máš pravdu, ale je to trochu přehnané - takhle to mají všechny nativní aplikace a myslím si, že obecně jsou tyto na serverech v průměru v převaze

[arny]

Vobec to nieje prehnane. Ked ti zrazu z nicoho nic padne cely web server a ty budes hladat kade tade po logoch a najdes akurat pad glibc koli dvojitemu uvolneniu pamate a vobec nebudes vediet, ktora z nativnych kniznic to urobila a preco, tak potom ti nebude do smiechu. Hlavne ked sa jedna o produkcny server. A ci su nativne aplikacie na serveroch v prevahe o tom by sa dalo polemizovat. Podla mna drtiva vacsina web aplikacii su vytvarane v php,java,.net a python a to vacsinou bez pouzitia nativnych kniznic.

[Luboš Doležel (Doli)]

Podla mna drtiva vacsina web aplikacii su vytvarane v php,java,.net a python a to vacsinou bez pouzitia nativnych kniznic.

Nevěděl jsem, že se bavíme o webových aplikacích...

[XMen]

sorry, nespomenul som to ale ano, hovorim o webovych aplikaciach. Kazdopadne problem vidim aj na desktopovych aj ked tam pad aplikacie neznamena pad aplikacie pre vsetkych jej uzivatelov. Aby som sa spravne vyjadril niesom proti nativnym knizniciam. Niekedy je to proste jedina moznost ci uz z dovodu pridania novej funkcionality alebo vykonu, ale treba si na ne davat podstatne vacsi pozor.

[kralуk]

Zkus si vzít ldd a vypsat si, na jakých všech nativních knihovnách (včetně zanořených) závisí běžný virtuální stroj nebo interpretr.
I. e. je potřeba si dávat na nativní a nenativní implementace zhruba stejný pozor...

[Bilbo]

Pokud je něco blbě naprogramovaný, tak je jedno jestli v Javě, nebo ne. Memory leaky se dají dělat i v Javě (stačí mít někde zapomenutou referenci na něco někde v nějakém seznamu - request odkazuje nas dokument, dokument odkazuje na session, session odkazuje na cookie a request ... , když se to dostatečně "dobře" zamotá, tak GC nemá šanci v tom chuchvalci referencí nic sklidit .... a o sklizeň se pak postará až OOM killer, který to ale vezme velmi důkladně), pokud "hlavní" vlákno aplikace/serveru postihne nějaký ten deadlock (i to se v Javě stává), tak sice technicky aplikace běží, ale prakticky je zralá akorát tak na odstřel.

Jeva je trošku odolnější vůči pár typům chyb díky trochu robustnějšímu managementu paměti a vyjímkám, ale všelék na nepadavou a vždy funkční aplikaci to není.

[Algi]

Já bych dokonce řekl, že memory leaky v Javě nejsou ani žádnou vzácností. Používat alespoň VisualVM se rozhodně vyplatí, dokáže to i odhalit díky leakům některé chyby v implementaci, které by si člověk jinak neuvědomil. A je úplně jedno, jestli to je webová či desktopová aplikace...