A programozási nyelv

Tartalomjegyzék Röviden az elôzményekrôl A nyelv legfontosabb tulajdonságai Egyszerû Objektumorientált Architektúrafüggetlen és hordozható Interpretált és dinamikus Robusztus és biztonságos Többszálú Elosztott Összefoglalás Végezetül néhány kérdés, kétely Fontosabb WWW címek

Pont ez az integetés az, ami megindokolja, hogy miért kell nekünk egy új programozási nyelv, amikor olyan jól megvoltunk mi az X-szel (itt mindenki behelyettesítheti a kedvencét). Ugyan a Jáva nyelv tulajdonságainak felsorolásánál megtalálhatunk számos olyan divatos kifejezést - pl. objektumorientált, párhuzamos, elosztott, stb. -, amik nélkül manapság egyetlen a valamire való programozót sem lehetne elcsábítani a kedvenc, ódivatú nyelvének pontosvesszôi és zárójelei mellôl, de ez még kevés lenne a sikerhez, elvégre világmegváltó nyelvek napról napra születnek. Szerintem a várható sikernek ezen felül két jelentôs indoka van: elôször is sok befolyásos számítástechnikai cég elhitte, hogy van benne fantázia és most - remélhetôleg - dôl a pénz a fejlesztésre.

A felhasználók szempontjából sokkal fontosabb a másik érv: a Jáva nyelv összeházasodott napjaink legdivatosabb számítástechnikai játékszerével, az Internet hálózattal. A házasságból egyelôre két gyermek született, a SUN HotJava- illetve a Netscape WWW böngészô programjának új, 2.0 verziója. Bár mindkét gyermek fejletlenke még, csak béta korúak, de már ki-kimutatják oroszlánkörmeiket, sôt újabb gyerekek érkezése is várható. Mellesleg a HotJava teljes egészében Jáva nyelven íródott, azt bizonyítandó, hogy a nyelv eléggé izmos ilyen méretû feladatok megoldására.

Egy ilyen Jávát értô böngészôvel az egér egyetlen óvatlan kattintására nem csak adatokat, de teljes, futni képes programokat is letölthetünk a kiszolgálóról, amely aztán el is indul a mi számítógépünkön. Akinek errôl a vírusok, férgek és egyéb rosszindulatú programok jut az eszébe, nyugodjon meg, késôbb még lesz errôl is szó!

Mire jó egy ilyen program? Hát természetesen bármire - a Jáva általános célú programozási nyelv -, a program nálunk fut, nem terheli az eredeti kiszolgálót, jópofa dolgokat rajzol, menükkel, párbeszédablakokkal tarkítja a képernyônkre, hangokat ad, egyszóval életet lehel a letöltött dokumentumba. Persze ennél többet is tehet, például felveheti a kapcsolatot azzal a kiszolgálóval, ahonnan hozzánk került és a két gép tisztességes elosztott rendszerként buzgón kommunikálni kezd, abból pedig bármi kisülhet.

A hagyományos böngészôk képesek arra, hogy az általuk ismert, elôre beprogramozott protokollokat - HTTP, FTP, Gopher, News, ... - használva felvegyék a kapcsolatot egy-egy kiszolgálóval és onnan adatokat töltsenek le, amelyeket, amennyiben a formátumát korábban ismerték - HTML, GIF, JPEG, ... -, akkor megjelenítsék. Viszont ha az URL-ben (a kiszolgáló gépet és az ott tárolt információt megadó címben) ismeretlen protokollt adtunk meg, akkor szegény böngészô kétségbeesetten széttárja a karját. Ha csak az adat formátuma ismeretlen, a helyzet egy fokkal jobb: a böngészô letölti a teljes adathalmazt, majd - ha szerencsénk van - továbbpasszolja a megjelenítés feladatát egy másik programnak, legrosszabb esetben tárolhatja azt a helyi lemezünkön, hátha majd egyszer megértjük, mi van benne. A Jávát értô böngészôkben viszont a kiszolgálóról letöltött Jáva programok bôvíthetik a felhasználható kommunikációs protokollokat (protocol handler) és a megjeleníthetô adattípusokat (content handler).

Az önállóan futtatható programok (application) és a böngészôk által letölthetô és futtatható "programkák" (applet) között nem nagy a különbség, legfeljebb csak a biztonsági meggondolások miatt a böngészôk szigorúbban figyelik, korlátozzák a hálózatról letöltött programkákat. Önálló programnál ilyen védelem nincs, a felhasználó nyilván tudja, mit és miért indított el.

A halózaton letölthetô programok ötlete új színt hoz az elosztott rendszerekben divatos ügyfél-kiszolgáló paradigmába: a programok igény szerinti letöltése (distributed on demand) elmossa a kiszolgáló és az ügyfél közötti éles határokat.

Röviden az elôzményekrôl

A projekt kezdetben a C++ nyelvet használta, ám a fejlesztôk ezt is, a többi, akkor hozzáférhetô programozási nyelvet is alkalmatlannak találták a célkitûzéseik maradéktalan megvalósítására, hát új nyelvet terveztek maguknak. Kiindulási alapként a C++ nyelvet használták, kigyomlálva belôle - az általuk - bonyolultnak, nem megbízhatónak talált szerkezeteket, hozzáadva innen-onnan átvett, hasznosnak tûnô ötleteket, nyelvi elemeket.

A felhasználói elektronikai alkalmazások lassabban fejlôdtek, mint azt elôre várták, a projekt szép csendben el is halt volna, ha közben az Internet hálózat nem indul rohamos fejlôdésnek. Szerencsére észrevették, hogy az Internet hálózat hasonló körülményeket teremt és hasonló igényeket támaszt egy új programozási technológiával szemben.

A nyelv legfontosabb tulajdonságai

Egyszerû	A nyelv szintaxisa és szemantikája nagyban hasonlít a sokak által ismert C illetve C++ programozási nyelvhez, megkönnyítve a kezdeti ismerkedést. A C++ nyelvbôl elhagytak néhány - programozói vagy fordítóprogram írói szempontból - bonyolult elemet. Kimaradt például az operátorok felüldefiniálásának lehetôsége (operator overloading), a többszörös öröklôdés. Eltûnt a goto utasítás, az automatikus típuskonverziók (coercion), az összetett adatszerkezetek közül a union, illetve C++-ban már amúgy is szükségtelen struct. 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] + "!"); } }
Objektum- orientált	Manapság az objektumorientáltság divatos programozási paradigma, bár a szakirodalom nem teljesen egységes a kritériumainak meghatározásában. A Jáva lényegében a C++ objektumorientált tulajdonságait tartalmazza. A programozó absztrakt adattípusként viselkedô osztályokat definiálhat, az osztályok mûveleteket - módszereket - tartalmaznak, amelyek a rejtett adatreprezentáción (egyedváltozók) operálnak. Létrehozhatunk objektumokat, azaz egyes osztályokba tartozó egyedeket. Osztályok definiálásánál felhasználhatunk már meglévô osztályokat, az új osztály (a leszármazott) örökli a szülô adatait, módszereit. A módszerek hívásánál a meghívott módszer futási idôben, objektum aktuális típusának megfelelôen kerül kiválasztásra (virtuális módszerek, polimorfizmus). 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.
Architektúra- független és hordozható	Napjaink hálózatait heterogén hardver- és szoftver architektúrájú számítógépek alkotják. A programok fejlesztését nagymértékben megkönnyítené, ha a forráskódból elôállított program bármely architektúrán azonos módon futna. Ezen cél elérése végett a Jáva nyelv nem tartalmaz architektúra- vagy implementációfüggô elemeket. A C nyelvvel ellentétben a beépített adattípusok (pl. int) mérete - tárolásához szükséges memória mérete, a típus értelmezési tartománya - nyelvi szinten meghatározott. 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.
Interpretált és dinamikus	Az interpretált végrehajtás - kombinálva a klasszikus kapcsolatszerkesztô (linker) helyett futás idejû betöltéssel - a fejlesztési ciklust nagy mértékben felgyorsítja. A Jávából eltûntek a C-bôl ismert header állományok, feltételes fordítás, más programállományok fordítás közbeni beolvasása (#include). A lefordított programok tartalmaznak a szerkesztéshez szükséges minden információt. Elég csak a megváltozott állományokat lefordítanunk - nincs szükség a C-nél megszokott make programra, a forrásállományok közötti függôségek feltérképezésére -, a program máris futtatható. Egyébként a Jáva támogatja a nagybani programozást, összetartozó osztályok egy csomagba (package) foghatók, egyszerre fordíthatók. A láthatóság is figyelembe veszi a csomagokat, a C++ explicit friend deklarációjának szerepét itt a csomagra - de csak a csomagra - vonatkozó láthatóság veszi át. A kapcsolatszerkesztô helyét az ún. osztály-betöltô (class-loader) veszi át, amely futás közben - ha szükség van rá - betölti az egyes osztályokat megvalósító lefordított, Byte kódú programállományokat. Az osztály-betöltô nem csak helyi állományokból, de szükség esetén a hálózaton keresztül is képes kódot letölteni. 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 (pl. regiszter allokáció optimalizálása), 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. Ugyanilyen korlátozásokkal használhatunk jelenleg fejlesztés alatt álló, béta változatú Java-C fordítóprogramot is, az így - egy C fordítóval - elôállított program lényegesen gyorsabban fut majd. 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.
Robusztus és biztonságos	Ez a két fogalom a Jáva esetében kéz a kézben jár. Robusztus egy nyelv, ha megakadályozza vagy futás közben kiszûri a programozási hibákat, biztonságos, ha megakadályozza, hogy rosszindulatú programok kerüljenek a rendszerünkbe. Mindkét célkitûzés eléréséhez gyakran hasonló módszereket használhatunk. 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. Folyik a Jáva és a Kerberos elosztott azonosítási (authentication) rendszer ötvözése, a Jáva programok "kerberizálása".
Többszálú	A programok jelentôs része párhuzamosan végrehajtható részletekre - vezérlési szálakra - bontható. Így jobban kihasználható a számítógép központi egysége, a programok a külsô - például felhasználói - eseményekre gyorsabban reagálhatnak. Az egymással kommunikáló, viszonylag laza kapcsolatban álló szálakra bontott feladat könnyebben áttekinthetô, megvalósítható és belôhetô. A többszálú programozáshoz a Jáva nyelvi szinten biztosítja az automatikus kölcsönös kizárást: szinkronizált (synchronized) módszerek vagy utasítások, valamint a szálak létrehozásához, szinkronizációjának megvalósításához a rendszerkönyvtár tartalmaz egy ún. Thread osztályt. A Thread osztály a Hoare-féle feltételes változók (conditional variable) modelljét követi. Természetesen az összes, a rendszerkönyvtárakban definiált osztály használható többszálú programokból anélkül, hogy aggódnunk kellene az esetleges hibás mûködés miatt (thread-safeness). 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ô.
Elosztott	A Jáva technológiát beharangozó ismertetôk mindenhol kiemelik, hogy a technológia elosztott (distributed) rendszerek létrehozását támogatja. Itt azért én megjegyezném, hogy az elosztottság eléggé cseppfolyós fogalom, a Jáva jelenleg sokkal kevesebbet tud, mint amit sokak - köztük én is - szeretnének. 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.

Összefoglalás

Persze a Jáva képességeivel nem egyedülálló napjaink számítástechnikájában. Hasonló úton indult el az Apple a Dylan rendszerével, a Microsoft pedig a Blackbird-del, emlegetnek egy Python nyelvet, a Free Software Foundation is foglalkozik virtuális gépen alapuló program-interpretálással és még lehetne sorolni a hasonól célú nyelveket, rendszereket.

Ha a Jáva nyelv mégis elterjed - márpedig szerintem erre minden esély megvan -, akkor ehhez hozzájárul a jó reklám, az ügyes marketing stratégia valamint a felhasználók és legfôképpen a szoftvergyártók erkölcsi és anyagi támogatása. Márpedig a szoftvergyártók tényleg ráharapni látszanak az új technológiára, olyannyira, hogy reménytelennek látszik teljes felsorolást adni azokról a cégekrôl, amelyek csatlakoztak, forrás licenszet vásároltak. Remélem nem sértem meg a kimaradókat, a teljesség igénye nélkül: a SUN-nál külön részleget hoztak létre a Jáva fejlesztésekre. A WWW szempontjából talán a legjelentôsebb esemény, hogy a Netscape megvásárolta a technológiát és integrálja az új böngészôjébe. Windows 95 alatti fejlesztôrendszerrel jelent meg a Symantec, hasonló termék kifejlesztését jelentette be a Borland, megvásárolta a technológia felhasználási jogát az IBM, sôt még a Microsoft is komolyan érdeklôdik.

Ha már a licenszekrôl beszéltem: nincs szükség licenszre ahhoz, hogy valaki Jáva programot illetve programkákat fejlesszen, a lefordított programot terjessze. Azon OEM szoftverfejlesztôk, akik a Jáva technológiát integrálni akarják termékeikbe, forrás licenszet vásárolhatnak.

A Jáva technológiához kapcsolódóan csomó név és grafika a SUN - regisztrált - védjegye. Ezek közül a cikk elején látott Duke és a HotJava szimbóluma, a gôzölgô kávéscsésze csak a SUN által használható. Hamarosan lesz egy ún. "Jávával turbósított" (Java Powered) grafika az olyan WWW lapokhoz, amelyek Jáva programkákat tartalmaznak, valamint egy "Jávával kompatibilis" (Java Compatible) grafika azon OEM termékeknek, amelyek elôállítói megvásárolták a forrás licenszet, termékükbe beépítették ezt a technológiát - pl. új architektúrára implementálták a virtuális gépet - és sikeresen megfeleltek a - most készülô - kompatibilitási tesztnek.

Ha valaki Jáva programokat akar fejleszteni, legegyszerûbb, ha a SUN-tól ingyenesen letölthetô Jáva Fejlesztôi Csomagot (Java Development Kit) használja, ami tartalmaz egy fordítóprogramot (javac), egy nyomkövetôt, hibakeresôt (jdb) a futtatáshoz szükséges virtuális gépet és egy a programkákat futtató alkalmazást (AppletViewer).

Ha valakinek komolyabbak a szándékai, a HotJava böngészô is szabadon hozzáférhetô. Igaz jelenleg a a fenti két programcsomag csak a Solaris 2.x, Windows 95 és Windows NT operációs rendszereken fut, bár más operációs rendszerek felé is hordozzák már a programokat. Az már csak apró, megbocsájtható fejlôdési rendellenesség, hogy a cikk írásának idején a JDK-val fejlesztett programkákat a HotJava nem tudja futtatni, lévén az utóbbi a Jáva könyvtárak egy régebbi változatát tartalmazza. Ezért vannak ún. alfa és béta programkák. Szerencsére a Netscape böngészô 2.0-s verziója ismeri az újabb, béta API-t használó programkákat és több operációs rendszeren is fut, még Linuxon is, de sem a Windows 3.1, sem Macintosh operációs rendszere alatt - egyelôre? - nem futtat Jáva programkákat.

Persze ha valakinek nincs olyan gépe, ahol a JDK-t futtathatja, ne csüggedjen, nagy az Internet hálózat, aki keres, talál olyan kiszolgálót, ahova elküldheti a Jáva programjának forrását, az lefordítja és visszaküldi az eredményül kapott programkát, amelyet a böngészô rögvest le is futtat.

Végezetül néhány kérdés, kétely

Az sem látszik még, hogy a technológiát mennyire fogja egy-két erôs cég a saját érdekeinek megfelelô irányba elvinni, avagy megmarad-e szélesebb körû érdekeket, véleményeket tükrözô, nyílt technológiának. A C++ nyelvre is ráfért az elmúlt években bekövetkezett, széles felhasználói kört megmozgató tisztázási, szabványosítási eljárás, gondolom a Jávának sem ártana. Nem látom például, hogy azon felül, hogy a Jáva karakterei 16 bites Unicode rendszerben vannak ábrázolva, valaki foglalkozna a nemzetköziesítés (internalization) kérdéseivel.

Sokan attól is félnek, hogy a "végleges" verzió megjelenése után a SUN szigorít a licensz politikáján, túl költségessé teszi a fejlesztôrendszerét, vagy pl. a HotJava-t. A WWW hálózat terjedésében jelentôs szerepet játszott az a tény, hogy a szükséges programok - kiszolgálók is, böngészôk is - szabadon hozzáférhetôk, ingyenesek voltak. Bár jelenleg a Netscape uralni látszik a böngészôk piacát, de nem biztos, hogy mindenki meg tudja, vagy akarja fizetni ennek az árát. Kérdés, hogy más kereskedelmi, vagy szabadon terjesztett böngészôk mennyire veszik át a Jáva technológiát, a WWW szerverek üzemeltetôi, a HTML lapok szerzôi mekkora potenciális, Jávát értô olvasótáborra számíthatnak.

Kiváncsi vagyok, hogy a felhasználók - fôleg a nagy cégek - mennyire fogadják el a rendszerbe beépített biztonsági mechanizmusokat. Elsô ránézésre megbízhatónak - ha néha túl korlátozottnak is - tûnik a rendszer, ám tapasztalatok szerint a vírusírók zseniálisak. Ha elôbukkan néhány biztonsági luk, a felhasználók bizalma hamar megcsappanhat, elvégre a hálózaton letöltött programok hiányos védelmi rendszer mellett potenciálisan hatalmas zûröket okozhatnak a helyi rendszerben.

Mindezen kérdések ellenére én bizalommal tekintek a Jáva jövôjére.

Lábjegyzetek

1

Talán sokan emlékeznek rá, hogy a SUN-nál már korábban is kitaláltak olyan érdekes, innovatív technológiákat, amelyek az üzleti vetélytársaknak nem nagyon tetszettek. Volt egyszer például egy News ablakozó rendszer, ami ellen elkezdték támogatni az MIT-n folyó X Window rendszer fejlesztést és létrehozták az X Konzorcium-ot. Késôbb a SUN beadta a derekát, ô is átállt az X-re, de ragaszkodott a saját ablakkezelôjéhez, az OpenWindows-hoz. Hát ezt sem szerették, így létrejött a Motif, és a SUN újra beadta a derekát ...

2

Bár itt Magyarországon a Jáva szót hallva az Indonéz szigetvilág egyik legnagyobb szigetére gondolunk, az amerikaiak inkább - a kezdetben onnan importált - kávéra (az elkészített italra) asszociálnak. Ezért találhatók a témakörben olyan elnevezések, mint HotJava, Digital Espresso...

Fontosabb WWW címek

Elsôdleges információforrások

• Sun JavaSoft részlegének címlapja
• Jáva 1.0 Fejlesztôi készlet

• Java World elektronikus újság
• Jáva hírcsoport

• Digital Espresso, hetenkénti összefoglalója a Jáva világ eseményeinek

Jáva gyûjtemények

• Yahoo Jáva gyûjteménye
• Gamelan Directory: a legnagyobb Jávával kapcsolatos gyûjtemény
• "Jáva Fejlesztôknek" a Digital Focus-tól
• John December összeállítása az online Jáva információkról
• Jáva Virtuális Könyvtár (ACM)
• Java User Resource Network

• Programkák a JavaSoft-nál
• Programkák a Netscape-nél

Jáva GYIK-ok (Gyakran Ismétlôdô Kérdések, FAQ)

• Jáva GYIK-ok gyûjtemény
• Eliotte Rusty Harold GYIK-ja
• comp.lang.java GYIK-ja

Bevezetôk a Jávával ismerkedôknek

• Sun bevezetôje
• Eliotte Rusty Harold bevezetôje
• Nelson Yu bevezetôi a Jáváról és az AWT-rôl
• "Hogyan kell ..." a Digital Focus-tól
• Java Workshop (Thingtone)

Jáva könyvekrôl

• A már megjelent és megjelenés elôtt álló könyvekrôl
• Arthur van Hoff, Sami Shaio, Orca Starbuck: Hooked on Java
• Laura Lemay, Charles L. Perkins: Teach Youself Java in 21 Days
• The Java Series at Addison Wesley

Jáva programozói verseny információk

• A nemzetközi versenyrôl
• A magyarországi versenyrôl

updated: 96/06/15, http://www.eunet.hu/infopen/cikkek/java/article.htm