Vlákno názorů k článku
Co bude dál s Javou od Sunu? od hisaak - Skutecne nechapu, kde se bere potreba otevrit zdrojove...

Súhlas.

Ja som sa v špecifikáciách Javy trochu hrabal a tak viem, že tie hardwarové nároky vyplývajú z príšerného návrhu bajtkódu a príšerných požiadaviek na interpreter.

Skompilovaná javovská aplikácia (.jar súbor) má formát veľmi podobný ako statické knižnice v Linuxe (koncept je úplne rovnaký, rozdiely sa týkajú iba nepodstatných detailov). To znamená, že ide o archív relokovateľných modulov, ktoré treba pred spustením zlinkovať do jedného uceleného bloku kódu. Každý z týchto relokovateľných modulov obsahuje skompilovaný kód presne 1 triedy (class), nezáleží na tom, či táto trieda je verejná alebo súkromná. To znamená, že keď vytvoríte súbor program.java obsahujúci 10 tried a dáte ho skompilovať, kompilátor vytvorí 10 relokovateľných modulov nazvaných classname.class, kde classname je identifikátor príslušnej triedy. Týmto relokovateľným modulom sa v Java slangu nadáva "class súbory".

Tou príšernou požiadavkou na interpreter je, že predtým, než akýkoľvek class súbor načíta, musí skontrolovať, či ide o platný javovský class súbor. Táto kontrola spočíva v traverzovaní častí tohoto súboru obsahujúcich inštrukcie Java Virtual Machine (tento zaberá väčšinu obsahu netriviálnych class súborov). Špecifikácia deklaruje, že určité časti tohoto kódu musia byť dostupné iba z jediného miesta v kóde, takže ak sa pri traverzovaní zistí, že tomu tak nie je, súbor je virtuálnym strojom odmietnutý a takisto je odmietnutá aj aplikácia, ktorá ho obsahovala. Ďalšie podmienky, ktoré musí kód spĺňať súvisia s používaním zásobníka a tak pri traverzovaní musí virtuálny stroj sledovať, ako vyzerá stav zásobníka na tej-ktorej inštrukcii virtuálneho kódu. Detaily viď "Java class file format specification". Toto traverzovanie kódu sa vykonáva pri každom spustení a vykonáva sa nad každým class súborom, ktorý sa pri spúšťaní dostane virtuálnemu stroju "pod ruku". Pointa je v tom, že drvivá väčšina javovskej štandardnej knižnice je napísané v Jave a je v systéme prítomná v podobe (čoho iného) .jar súboru. To znamená, že obsah tejto knižnice musí virtuálny stroj (v súlade so špecifikáciou) kontrolovať, čiže traversovať kód v nej obsiahnutý. Táto knižnica má asi 20 MB, takže ak aplikácia využíva väčšinu z nej, strávi virtuálny stroj spúšťaním aplikácie rádovo minúty až desiatky minút.

Problém nie je v samotnom kontrolovaní platnosti súboru (v prípade Javovských appletov toto bráni útočníkom v tom aby podhodili poškodený javovský class súbor a potom profitovali z nejakého buffer overflow alebo spôsobili pád WWW prezerača alebo dokonca celého systému obete). Problém je v tom, že virtuálny stroj si vôbec nepamätá, že daný súbor už v minulosti kontroloval a zistil, že neobsahuje žiadny problém a tak ho musí kontrolovat znovu a znovu a znovu.

Druhý problém spočíva v tom, že formát .jar súboru je javovský ekvivalent formátu Linuxovej statickej knižnice. Je síce pravda, že Java nekopíruje kód použitých procedúr so štandardnej knižnice do aplikácie (takže z pohľadu spustenia ide o "shared libraries") ale fakt, že vnútri sú "relokovateľné moduly" namiesto zlinkovaného bloku kódu spomaľuje virtuálny stroj (nie je známe, či sa spomalenie týka len štartu aplikácie alebo aj jej samotného behu) a pravdepodobne prispieva aj k zvýšeným pamäťovým nárokom. Ako je to s detailami práce virtuálneho stroja pri vykonávaní javovskej aplikácie, to je pravdepodobne známe iba programátorom Sunu.

Keby som ja navrhoval formát bajtkódu pre Javu, určite by som sa nechal inšpirovať strojovým kódom súčasných počítačov v tom zmysle, že kód aplikácie by bol "zlinkovaný" do jedného súvislého bloku a tak by bolo možné zo súborov vyhodiť väčšinu názvov tried a metód. Názvy tried a metód importovaných z použitých knižníc by boli v súbore iba raz (neopakovali by sa pre každú triedu, ktorá daný názov potrebuje). A tiež by som sa zamyslel nad tým, aby si virtuálny stroj vedel nejako zapamätať, ktoré súbory už úspešne skontroloval.

No čo už.