A  programozási nyelv

Tartalomjegyzék

 Fontosabb WWW címek 

 Azért szerencsére nem gyomláltak ki mindent a C++-ból, megmaradt például a futásidejû hibák lekezelésének mechanizmusa, az. ún. kivételkezelés (exception handling). Bár az "igazi programozók" megkönnyezik az eltávozott goto utasítást, de helyette címkézett ciklusokat, többszintû break és continue utasítást kaptunk.

 Sokaknak elsõre - többeknek talán másodszorra is - furcsa, de a Jáva nem használ mutatókat (pointer), egy csapásra megszûntetve ezzel a C programozók kedvelt programozási hibáinak egész seregét. A programozó munkáját nagymértékben megkönnyíti az is, hogy a nyelv automatikusan felszabadítja a már nem használt tárterületeket (szemétgyûjtés, garbage collection).

 Ízelítõül álljon itt a kötelezõ "Szervusz világ" program egy kicsit módosított változata, amely az elsõ paraméterben megadott szöveget írja ki a "World" helyett, már amennyiben van ilyen. 

class HelloWorldApp

{

   public static void main (String args[])

   {

      System.out.println("Hello ");

      if (args.length == 0)

         System.out.println("World!");

      else

         System.out.println(args[0] + "!");

   }

}

 Az egyes osztályokban definiált változók és módszerek láthatóságát a C++-ban megismert módon - private, protected és public - lehet megadni.

 Eltérést jelent a C++-hoz képest, hogy a Jávában a beépített, egyszerû adattípusú - numerikus, logikai és karakter típus - változók kivételével minden objektum; az egyetlen összetett adattípus, a tömb (array) teljes értékû osztályként viselkedik. A program nem tartalmaz globális változókat és globális eljárásokat, minden adat és eljárás valamilyen objektumhoz, esetleg osztályhoz kötõdik. Persze a C++-t ismerõk tudják, hogy a globális változókat és függvényeket helyettesíteni lehet ún. osztályváltozókkal és statikus függvényekkel, ezek itt is használhatók.

 A Jávában minden módszerhívás - a fent említett statikus módszerek kivételével - virtuális. A C++-hoz hasonlóan lehetõségünk van az egyes objektumok típusát futási idõben lekérdezni (ez a C++-ban is viszonylag új nyelvi elem az ún. RTTI, Run-Time Type Interface), sõt itt akár az osztályok forrásprogramban definiált nevét futás közben is felhasználhatjuk például objektumok létrehozására. Az osztályok mellett a Jáva az Objective-C programozási nyelvbõl átvette az Interface fogalmat. Az Interface nem más, mint módszerek egy halmaza - adatszerkezeteket, egyedváltozókat nem tartalmaz -, amelyet egyes osztályok megvalósíthatnak (implementálhatnak). A Jáva a C++-szal ellentétben nem engedi meg a többszörös öröklõdést, viszont Interface-ek használatával, egyszerûbben, kevesebb implementációs problémával hasonló hatást lehet elérni. 

 Ahhoz, hogy a lefordított program változtatás nélkül futtatható legyen különbözõ hardver architektúrákon, a fordítóprogram a programot nem egy konkrét processzor gépi kódjára, hanem egy képzeletbeli hardver - virtuális gép (virtual machine) - utasításrendszerére fordítja le. Az így létrejött közbülsõ, ún. Byte kódot töltjük le a célarchitektúrára, ahol a virtuális gépet megvalósító program értelmezi és hajtja végre.

 A hordozhatóság nem csak a virtuális gépi utasítások, hanem a nyelv mellet szabványosított rendszerkönyvtárak szintjén is jelentkezik, ezek a könyvtárak valósítják meg a legfontosabb, operációs rendszerekhez kötõdõ feladatokat, mint például a be- és kiviteli rendszert, vagy a programok grafikus kezelõi felületét.

 Egy új architektúrán akkor futtathatók a Jáva programok, ha már implementálták rá a virtuális gépet, beleértve a rendszerkönyvtárakat is. A virtuális gépet C-ben írták, a kód POSIX.1 szabványnak megfelelõ operációs rendszert tételez fel, így viszonylag kis munkával hordozható. A hordozhatóság érdekes aspektusa a fejlesztõi környezet hordozhatósága. A környezet egyes részei, mint például a fordítóprogram, nyomkövetõ eszközök, vagy maga a HotJava böngészõ is Jáva nyelven íródott. Na és ha a Jáva programok hordozhatók, akkor hipp-hopp (?), az egész környezet is átkerült az új architektúrára. 

 Többek között a betöltõ feladatának megkönnyítése végett a Byte kód tartalmaz a forráskódból átvett szimbolikus- illetve típus információkat. Lássunk egy példát arra, hol jöhet jól ez az információ.

 Az objektumorientált programozási paradigma egyik nagy ígérete, hogy általános célú, könnyen felhasználható osztály-könyvtárakat, "szoftver-IC-ket" hozhatunk létre a segítségével. Sajnos a C++ nyelv ilyen tekintetben nem váltotta be teljesen a hozzá fûzött reményeket. Nagyon nehéz olyan osztályokat tervezni, amelyeket késõbb nem kell majd úgy módosítani, hogy ne kelljen azt például új - bár a programozók elõl rejtett - adatkomponensekkel vagy módszerekkel bõvíteni. Bár az osztály külsõ interfésze nem feltétlen változott meg, ám a C++ az osztály reprezentációját, tárbeli elrendezését kihasználó fordítási mechanizmusa miatt ilyenkor az összes, a megváltozott osztályt - akár csak öröklésen keresztül - felhasználó programot újra kell fordítani. Ezt hívják "törékeny alaposztály" (fragile base class) problémának. A Jáva ezt a problémát úgy kerüli meg, hogy az osztályok adatkomponenseire, módszereire a Byte kódban is szimbolikusan hivatkoznak, a hivatkozások konkrét címekké kötése csak futási idõben, a virtuális gépben történik meg.

 A közbülsõ kódban megmaradt szimbolikus információk megkönnyítik a programok nyomkövetését. Sajnos az interpretált végrehajtásnak van egy nagy hátránya is, a programok sokkal - becslések szerint 10-20-szor - lassabban futnak, mint a gépi kódú megfelelõik. Bár a virtuális gép elég ügyesen lett kitalálva és a fordítóprogram is mindent megtesz azért, hogy ezt a virtuális architektúrát a lehetõ legjobban kihasználja, de még így sem vetekedhet a gépi utasítások sebességével. Ehhez még hozzáadódik a szimbolikus hivatkozások feloldásának ideje, a különbözõ betöltési- és futásidejû ellenõrzések - ld. késõbb -, a tárgazdálkodási modellel járó szemétgyûjtési algoritmus futásához szükséges idõ.

 E lassúság ellen jelenleg nem sokat tehetünk, legfeljebb azzal vigasztalhatjuk magunkat, hogy az alkalmazások jelentõs részénél - gyakori felhasználói közremûködést, vagy hálózati kommunikációt igénylõ programoknál - a program sebessége nem a legfontosabb követelmény. Persze a Jáva programok meghívhatnak gépi kódú (native) eljárásokat is, de ezzel elvesztjük az architektúra- függetlenség, hálózaton letölthetõség tulajdonságát. De bejelentettek olyan fordítóprogramot is, amely közvetlenül gépi kódra fordít.

 Legígéretesebbnek az úgynevezett "röptében fordítás" (just-in-time, on-the-fly compilation) ötlete tûnik. A Byte kód úgy tele van tömve szimbolikus információkkal, hogy elvileg nem nehéz - ezt kiindulási nyelvnek tekintve - optimalizáló fordító programot írni hozzá. Ráadásul a virtuális gép utasításrendszere nagyon hasonlít napjaink processzoraiéhoz, könnyû belõle jó kódot generálni. A fordítás történhet az egyes osztályok betöltésekor - a szükséges ellenõrzések után -, esetleg végrehajtás közben. Futás közben esetleg az is eldõlhet, hogy érdemes-e az adott programrészletet lefordítani, mert gyakran használjuk, avagy megmaradhat interpretáltnak.

 Másik érdekes kísérlet, hogy a Sun a Jáva virtuális gépet sziliciumon is megvalósítja, hamarosan kaphatók olyan mikroprocesszorok, amelyek a Jáva Byte kódot közvetlenül futtatják. 

 A robusztusság nyelvi szinten a szigorú, statikus típusosságban jelenik meg. Minden adatnak fordításkor jól definiált típusa van, nincsenek automatikus konverziók, az explicit konverzió csak kompatibilis típusoknál sikerül, egyébként legkésõbb futtatáskor programhibát (exception) okoz. A mutatók eltûnésével rengeteg potenciális hibalehetõség eltûnt a nyelvbõl - pl. NULL pointer hivatkozás, levegõben lógó mutatók -, persze elvesztettük az "igazi programozók" egyik kedvencének, az int-eknek és a mutatóknak ide-oda alakítgatásának lehetõségét is. A dinamikus szemétgyûjtés megkímél bennünket a hasznos memória elszivárgásától (memory leak). Az egyedüli összetett adatszerkezet, a tömb használatakor a túlcímzést futási idõben ellenõrzik. Az osztály-betöltõ arra is figyel, hogy a módszereket megfelelõ típusú paraméterekkel hívjuk meg.

 A biztonság (security) a robusztussággal kezdõdik, a fordító csak korrektül viselkedõ programokat ad ki magából. Ez elegendõ lehet önálló alkalmazásoknál, de a programkák letöltésénél ennél többre van szükség. Kezdjük azzal, hogy ki garantálja, hogy a letöltött Byte kódot valóban egy megbízható Jáva fordító hozta létre, nem pedig egy bit-betyár barkácsolta össze a hexadecimális szerkesztõjével? A Byte kód minden utasítása információt tartalmaz az operandusok típusáról, az osztály-betöltõ - függetlenül attól, hogy a helyi háttértárról vagy a hálózatról tölt be - ellenõrzi, hogy a program megfelel-e a nyelv szabályainak. Eldönti például, hogy minden operandus valóban a megfelelõ típusú, nem használjuk ugyanazt az adatot más-más típusúként is. Ellenõrizhetõ az is, hogy a módszerek a vermüket konzisztensen használják-e, valamint hogy a kód nem fér-e hozzá számára nem engedélyezett - a nyelv definíciója szerint láthatatlan, rejtett - adatkomponensekhez, módszerekhez.

 A betöltõ egy hivatkozott osztályt elõször mindig a helyi háttértárból próbál betölteni, csak akkor fordul a hálózaton elérhetõ kiszolgálóhoz, ha az osztály nincs meg a helyi rendszeren. Így elkerülhetõ, hogy trójai falóként valamelyik rendszerkönyvtár helyett azonos nevû, távolról betöltött programot futtassunk.

 Ha a betöltött programkák átjutottak a betöltõ konzisztencia-ellenõrzésén, akkor a virtuális gép felügyelete alatt kezdenek futni, ez ellenõrzi, hogy a programok csak engedélyezett tevékenységet hajtanak végre. Szigorúan szabályozott - vagy teljesen tiltott - például helyi állományokhoz való hozzáférés, tiltott más helyi programok indítása, jelentõsen korlátozott a hálózaton felvehetõ kapcsolatok címzettje.

 Sajnos ezen biztonsági szabályok erõsen korlátozzák a programkák képességeit. Biztonsági szempontból legfeljebb a helyi rendszerbõl betöltött - többé-kevésbé megbízható -, illetve hálózatról letöltött - eleve gyanús - osztályok között lehet különbséget tenni. Késõbbiekben lehetõség lesz nyilvános kulcsú titkosítás segítségével azonosítható forrású, garantáltan eredeti, változatlan, "megbízható" programok letöltésére és futtatására is. 

 A Jáva virtuális gép a szálak futtatásához prioritáson alapuló preemptív - de nem feltétlenül idõosztásos - ütemezõt tartalmaz. Ez magyarázza például azt, hogy - a jelentõs felhasználói igények ellenére - nem született még Jáva virtuális gép a Microsoft Windows 3.1-es - csak kooperatív ütemezést tartalmazó - rendszerére.

 A többszálú programozás támogatása ellenére a Jáva nyelv - legalábbis mostani változatában - valósidejû programok írására nem alkalmas. A virtuális gép nem tartalmaz határidõs ütemezési képességeket, de még a prioritás-öröklést sem ismeri, a jelenleg implementált szemétgyûjtõ algoritmus sem alkalmas valósidejû futtatásra - bár ez utóbbi a virtuális gép "magánügye", a programok változtatása nélkül könnyen lecserélhetõ. 

 Az elosztottság jelenleg két formában jelenik meg: mint már említettem, az osztály-betöltõ képes Jáva Byte kódot a hálózaton letölteni. Ezen túl a rendszerkönyvtárak tartalmaznak a TCP/IP protokollcsalád alacsonyabb, szállítási (TCP és UDP), valamint magasabb, alkalmazói (pl. FTP, HTTP) szintû protokollok kezélésére szolgáló osztályokat.

 De egy Jáva program nem elosztott objektumorientált rendszer, nincs mód távoli objektumok létrehozásra, transzparens távoli módszerhívásra. Viszont komoly, biztató kisérletek történnek a Jáva és a CORBA (Common Object Request Broker Architecture) összeházasítására, de láttam már a hálózaton CORBA-tól független, de hasonló funkciókat nyújtó kisérleti osztály-könyvtárat is.