Mint mindenhol, a számítástechnika világában is sokféle tévhit és legenda kering. Van, ami teljesen alaptalan, van, amelyiknek akad némi alapja, de csak szélsőséges körülmények között mondható igaznak, vannak „túlfújt” hibák, és vannak olyan tévhitek, amelyeknek valaha létezett alapja, de ma már nem igazán van. Az egyik tévhitektől hemzsegő témakör a Java, amiről főleg az terjeng, hogy „lassú” és hogy „sok memóriát foglal”.

A Javáról röviden, a teljesség igénye nélkül

A Java egy programozási nyelv, ami a C és a C++ mintáját követi, viszont az előbbiből generált virtuális gépi kód (ún. „byte-kód”) a JVM (Java Virtual Machine) nevű virtuális gépen fut, ellentétben a C/C++ programoknál, amelyek valós gépi kódra fordulnak.

A Java virtuális gép a már említett byte-kódot valós időben fordítja gépi kódra, amit JIT (Just In Time) feldolgozásnak neveznek. Mindezt úgy teszi, hogy fordítás közben elemzi is a kódot, és optimalizál rajta, ha lehetséges, így fordulhat elő az, hogy bizonyos feladatoknál gyorsabb lehet, mint a hagyományosan futtatott programok. Ugyanakkor az elsődleges cél mégis csak a platformfüggetlenség, valamint az automatikus memóriakezelés biztosítása.

JAVA

A platformfüggetlenség azt jelenti, hogy a program minden olyan processzoron és operációs rendszeren futni fog, amire elérhető a Java futtatókörnyezet (amely tartalmazza a JVM-et, a Java alap függvénykönyvtárait és a fordítót), legyen akár x86-, Power- vagy ARM-processzor a gépben, de a Java az operációs rendszerek között sem válogat.

Az automatikus memóriakezelés pedig leveszi a programozó válláról a memóriakezelés súlyát, ami jelentősen gyorsítja a fejlesztést, és sok hibalehetőséget zár ki. Igaz, az automatikus memóriakezelés megoldható JIT nélkül, nem virtuális gép alapú környezetekben is.

A Java programok memóriaéhsége pedig nem mindig annyira vészes, mint amennyire annak látszik, ugyanis az ilyen alkalmazások szeretnek sok RAM-ot lefoglalni maguknak, viszont az egyáltalán nem biztos, hogy ki is használják azt.

A lefoglalt memóriaterületet „heap”-nek hívják, és mindegyik Java futtatókörnyezetnek (több is van ám!) van egy alapbeállítása, hogy mennyi memóriát foglaljon le erre a célra, HA az alkalmazásban nem szabott meg a programozó egy saját értéket (amit általában nem szoktak), pedig manuálisa állítva be a minimális értéket bizony csökkenteni lehet a memóriaéhséget. Azért hozzá kell tennem, hogy manapság a nem Java alapú programok is felnőttek a Java szintjére memóriaéhség szempontjából, viszont a régi szövegek ismételgetés megmaradt…

A tévhitek

Gyakran ismételgetett probléma Java témában a nyelv állítólagos lassúsága. Ennek a sztorinak két forrása van: az egyik, hogy a  Java alapú programok boot utáni első indulásakor be kell tölteni a futtatókörnyezetet is, na meg a függvénykönyvtárak egy részét (körülbelül 250 MB a futtatókörnyezet jelenleg), ami töredezett merevlemezeknél eltart pár másodpercig -- viszont ha körülnézünk, láthatjuk, hogy manapság ez nem kirívó adatmennyiség.

JAVA

A másik forrása a lassúság „legendájának” pedig az, hogy a programok általában lassabbak az ilyen virtuális gépes környezetben, mint a natív, gépi kódú alkalmazások. Ennek az állításnak is van alapja, hiszen a Java első kiadása bizony 20 éve, 1995-ben indult útjára, és az akkori számítógépek finoman szólva nem dúskáltak sem memóriában, sem pedig processzorerőben, viszont azóta eltelt pár év, a gépek sokkal gyorsabbak, és maga a futtatókörnyezet is jelentősen gyorsult az időközi optimalizációknak köszönhetően. Lásd a Jake2 nevű Javában írt Quake2 klónt, ami alig lassabb mint az eredeti, C-ben írt, natív változat!

Látható, hogy a Java platformot ért támadások nagy része manapság inkább megszokás alapú, olyan „hallottam egy ismerőstől, hogy a barátja használta és gáz” típusú értesülésekből áll össze, és az is rásegít a rossz hírnévre, hogy az ilyen alkalmazások könnyen felismerhetők a laikus számára is, hiszen .exe helyett általában .jar kiterjesztésű a futtatható program, és a Java futtatókörnyezet telepítésének megkövetelése is árulkodó. 

A Java nincs egyedül

Van egy másik virtuális gép alapú környezet, ami a Java klónjának mondható, teljesítménye hasonló (habár betöltődés szempontjából még lassabb, hiszen jóval nagyobb helyet foglal a környezet, ráadásul sok fájlban szétszórva), és valahogy elkerülik a károgók, ami nem véletlen.

Ez a Microsoft által fejlesztett C# és a .NET környezet, melynek megalkotása annak köszönhető, hogy a 2000-es évek elején a Javát fejlesztő Sun beperelte a redmondiakat, akik éppen nagyban fejlesztették saját céljaikra módosított Java futtatókörnyezetet és függvénykönyvtárakat, az MS Javát, és így ki kellett találniuk valamit, ami olyan, mint a Java, de még is kicsit más...

Ezekről a .NET-es alkalmazásokról a laikus felhasználó nem tudja, hogy bármiben is különböznek a natív programoktól, hiszen .exe kiterjesztésűek a futtatható fájlok, és a .dll kiterjesztésű függvénykönyvtárak is a natív programokra hasonlítanak, na meg a futtatókörnyezet alapesetben is az újabb Windowsok része. Ez jó ötlet volt, hiszen amiről nem tudnak a félinformációkból tájékozódó a hangulatkeltő felhasználók, arról nem is fognak elméleteket vagy tévhiteket gyártani. Bizony, a Java hallatán károgók is rengeteg ilyen szoftvert használnak nagy megelégedéssel, csak nem tudnak róla, hogy a háttérben ugyanaz megy, ami a Java esetében. Egy példa akad, amiről tudja szinte mindenki, hogy C# alapú .NET környezetben futó alkalmazás: a hírhedten lassú Catalyst Control Center, bár ennek csigatempója miatt inkább az alkalmazás programozói okolhatók, és nem a futtatókörnyezet.

.NET Framework

Most jön a csavar! Java (vagy akár C#) nyelvben írt programot bizony lehet akár gépi kódra is fordítani, akárcsak a hagyományos programnyelvekben írt alkalmazásokat, viszont így elveszik a JIT esetleges előnye és a platformfüggetlenség, ugyanakkor az alkalmazás nem lesz számottevően gyorsabb, így nagyon ritkán van létjogosultsága ennek a stratégiának.

Szép példa erre az Android (amit szintén erős tévhitek öveznek, melyek közül sokat a Javától, sokat pedig az Androidot szétgányoló gyártói sufnituningoktól örökölt), amelynél éppen mostanában állnak át a Dalvik VM-ről (ami szintén olyan virtuális gép, mint a JVM, csak ezt a Google fejlesztette) ART környezetre, ami lényegében natív kódot készít az alkalmazás telepítésekor. Sajnos itt sem egyértelműek az előnyök, helyenként akár több memóriát igényelnek és lassabbak ezek a natív kódra fordított az alkalmazások, mint a Dalvik virtuális gép alatt, viszont megéri még így is a Google-nek a váltás, hiszen így remélhetőleg megússza a VM rövidítés, vagy „virtuális gép” kifejezés hallatára a platformnak ugró, vérben forgó szemű „szakértőket”.

És itt az újabb párhuzam: a Windows Phone-t nem szokták lassúsággal vádolni, pedig a WP alkalmazások túlnyomó része bizony virtuális gép alapú, csak ugye ott a C# és a .NET kombó játszik, és nem köthető össze a Java „szitokszóval”.

A Java tehát a desktop felhasználóknál nem túl népszerű a sok tévhit és a nem túl megalapozott „szakértői” vélemények miatt, miközben ironikus módon az ugyanolyan elven működő, Java mintájára készült, hasonló teljesítményű, és nyelvileg is nagyon hasonlító C# és .NET platform virágzik. Persze azért a Javát sem kell félteni, mert a fent említett pszichológiai hatásokra kevésbé érzékeny nagyvállalati környezetben szinte egyeduralkodó, emellett Androidon is ez marad az elsődleges fejlesztői nyelv.