Coz tedy mimo jine znamena, ze neni jasne, jak se JVM zachova, pokud bude mit
struktura ClassLoaderu hodne nechutnou podobu - ClassLoader v ClassLoaderu v
ClassLoaderu a teprve v tech treti urovni bude nacitana knihovna, pricemz pri
kazdem redeployi se zahodi ty druhourovnove ;-)
Nemyslim ze to je jasne... Staci pozriet do zdrojakov a je to
jasne...:-) Vsetko podla hesla: Najlepsia dokumentacia je kod samotny... :-)
Ale podme spat k veci:
Z redeployom je problem takmer vsade tomcat,oc4j,wls,... Nie je to
problem servera ako takeho, ale javy samotnej. Nie je zial mozne donutit
javu aby unloadla nativnu kniznicu nahratu v nejakom classloadery.
Avsak: pokial gc uprace dany classloader, tak sa aj nativna kniznica
uprace (unloadne) korektne. Na toto sa mozete spolahnut (teda aspon
podla zdrojakov). Problem je avsak v tom ze v jave nemate na 100%
zarucene ze ked nieco nie je referencovane tak Kedy sa to uprace. A tu
je jadro problemu... :(
Ale ak by vam to vadilo tak mozno by slo ze by ste si urobili vlastnu
implementaciu runtime-u, upravit si gc a woalla vynajdete Java RTS..."0
Este 2 zaujimave pikosky bokom od hlavneho problemu povodneho tazatela
ohladom JNI:
- nativnu kniznicu musite loadovat v triede v ktorej sa nachadzaju
nativne metody v nej definovane... Skoda, stacilo by keby bola len
poziadavka na ten isty classloader, nie tu istu triedu :(
- Nemozete mat 2 web/ejb aplikacie ktore pouzivaju jednu nativnu
kniznicu bez toho aby ste danu triedu ktora obsahuje nativne metody dali
o classloader vyssie... :-((
Zial s realnym pouzitim JNI v jave to nie je az take ruzove ako to
hlasaju marketingove materialy...
A preto... kodujte cisto.. 100% pure java... :-)))
Nechcete to nekdo testnout? ;-)
