Docela slibny uvod, uvidime jak se vyvinou dalsi dily. Clanek tohoto typu mi na rootu chybel. Mam podobne zkusenosti jako autor: nekteri lidi maji porad vuci Jave predsudky typu, ze je pomala, ze by pro spousteni javaprogramu museli mit nainstalovane stovky MB knihoven, atd. Vyvracet tyhle myty je nekdy velka drina. Pokud pujdou i ostatni dily spravnym smerem, konecne nebudu muset vsechno zdlouhave vysvetlovat sam, ale jenom predam odkaz sem. Jsou to vsechno sice jenom elementarni veci, ale asi ne pro lidi co se javou nezabyvaji (odmitaji zabyvat?).
Co se tyce virtualni masiny, doporucuju pouzivat JRE 1.4.x od Sunu. Je mnohem rychlejsi nez predchozi verze.
To je sice pravda, ale pokud mate zkusenost s .NET aplikacemi, tak pro jejich beh je taky treba nainstalovat .NET Framework a to je take kolem 40MB. Takze M$ se ubira stejnym smerem (s tim rozdilem, ze v nove verzi to samozrejme bude pevnou soucasti systemu a zrejme to nepujde odinstalovat). A jejich priznivci budou proti Jave argumentovat tim, ze .NET je lepsi, protoze neni nutne nic stahovat a instalovat.
Ale diky za clanek. Tohle sice mam uz davno za sebou, ale urcite to pomuze rozsirit Javu.
SWING GUI ma rekneme na horsim PC vyssi rezii, to ano, ale samotny procesni vykon javy (napr. v serverovem reseni) obzvlast za pouziti HOTSPOT VM si myslim neni vubec spatny.
Pravda je, ze JRE neco na disku zabira, ale rozhodne to neni zadna astronomicka suma. Samotne knihovny vyuzivane java aplikacemi (v *.jar) uz pak mivaj jen radove desitky kB
Ale pravda je, ze ten mytus o pomalosti tady bude porad :-) A po pravde receno - furt je mi milejsi parvterinova latence pri zavadeni trid , nez zavislost na cemkoli proprietarnim od micro$oftu. 5 let sem vyvijel pod win32 a posledni rok uz jen v jave a popravde - dusevne se citim daleko lepe po tom, co sem se zavislosti a vlaceni se MS obchodnimi zajmy zbavil :-)
Logicky interpretovany kod nemuze byt nikdy tak rychly jako nativni. Pokud je, znamena to ze ten nativni je mizerne zoptimalizovany (stava se casto) nebo ze je neco schnileho v architekture (u i386 nelze vyloucit).
Na druhou stranu, zda se ze v interpretovanych jazycich se programuje rychleji ...
Swing ma na jakemkoliv PC velkou rezii. Co znamena, ze samotny vykon Javy vubec neni spatny? Java je IMHO pres vsechny Jit a HotSpot proste pomala. Perl ma garbage collecting, je interpretovany a rychlostne je nekde jinde.
Nojo, ale Perl neni multivlaknovej. Uz se o tom mluvi dlouho, ale porad to jeste neni hotovy. Mutlivlaknovost Perlu mi dost chybi. Pokud si treba udelate perl backend k openldapu, tak musi server pozadavky obsluhovat sekvencne, protoze volani
perl interpretu je obaleny spin lockem.
Podobne je to s webem. Pokud chcete drzet konexe do DB a sdilet je, tak zjistite, ze to v Perlu proste nejde.
To je vtip, ne? Nemaji uvedeny perlovy zdrojak, na kterem to merili. Nemaji uvedeny, jakym interpretem Perlu to pousteli. Nemaji tam napsane, nad jakym JVM bezel ten javovy kod a cim byl prekladany. Je to uzce zamerena uloha: nazyvat hromadu volani indexOf() "pattern matchingem" jak by vypadlo z Monty Pythonu. One cross each :)
