![[Szálak állapota]](thrstate.gif)
A bevezetô példa a Internet hálózat világába visz el bennünket. A drótposta (email) továbbítására itt az ún. SMTP (Simple Mail Transfer Protocol) protokoll használatos. A levéltovábbító programok (Message Transfer Agent, általában a sendmail program) a 25-ös TCP kapun várakoznak arra, hogy valaki kiépítse velük a kapcsolatot, ha a kapcsolat létrejött, egy nagyon egyszerû, karakterorientált párbeszédbe kezdenek a hívóval. A párbeszéd egy ritkán használt, de néha nagyon hasznos parancsa, a VRFY (Verify) segítségével megkérdezhetjük egy SMTP kiszolgálótól, hogy egy adott nevû felhasználónak van-e a gépen postaládája.
A mi programunk pontosan ezt csinálja, a
java SMTPclient host user
parancs hatására a host számítógép SMTP szerverétôl a user felhasználó felôl érdeklôdik, a kapott választ pedig kiírja a konzolra.
Lássunk egy példa párbeszédet a két gép között! Dôlt betûkkel a megszólított SMTP kiszolgáló (a hapci.mmt.bme.hu gépen), normális betûkkel az ügyfél, a mi programunk (a tudor.mmt.bme.hu gépen) üzenetei láthatók. A példa egy sikeres és egy sikertelen lekérdezést is tartalmaz.
220 hapci.mmt.bme.hu 5.65c8/BMEIDA-1.4.4 Sendmail is ready at Wed, 14 Feb 1996 17:31:03 +0100 HELO tudor.mmt.bme.hu 250 Hello tudor.mmt.bme.hu, pleased to meet you VRFY kiss 250 Kiss Istvan <kiss> VRFY duke 550 duke... User unknown QUIT 221 tudor.mmt.bme.hu closing connection
Látható, hogy a kiszolgáló minden üzenetét egy számmal is kódolja.
C programozók figyelem: ez nem #include parancs, nem a fordítóprogramnak szóló üzenet a forrásszöveg beolvasására. Az import a kapcsolatszerkesztônek, betöltônek szól, már lefordított kódú könyvtárakra hivatkozik. Importálásnál csomagokból (package) osztályokat (class) importálunk, azaz a programunkban felhasználhatóvá tesszük. A csillag az adott csomag összes osztályát jelenti.
import java.net.*; import java.io.*; import java.lang.*; import java.util.*;
Ezután rögtön egy osztálydeklarációnak kell következni, a Jáva programban minden változó, minden utasítás csak osztályok törzsében szerepelhet. Eltûntek a C globális változói, globális függvényei.
Aki most lát elôször C++-ból átvett osztálydeklarációt, ne essen kétségbe, egyelôre fogadja el, hogy még a legegyszerûbb Jáva program is a
class osztálynév { ... }
mintát követi. Az osztálynév-ben, mint a Jáva minden azonosítójában, a kis- és nagybetûk különbözôek.
class SMTPclient
{
típus változónév [ = kezdeti_érték ]
A nyelv tartalmaz néhány beépített, egyszerû adattípust, amelynek neve és értékkészlete a következô táblázatban található:
| egész típusok | byte | 8 bit kettes komplemens |
| short | 16 bit kettes komplemens | |
| int | 32 bit kettes komplemens | |
| long | 64 bit kettes komplemens | |
| valós típusok | float | 32 bit IEEE 754 lebegôpontos |
| double | 64 bit IEEE 754 lebegôpontos | |
| karakter típus | char | 16 bites Unicode karakter kód |
| logikai | boolean | true vagy false |
Látható, hogy csak elôjeles egész típusok vannak, bár ez nem jelenti azt, hogy nem lehet rájuk például a szokásos bitmûveletek alkalmazni. A C-tôl eltérés az is, hogy itt az egyes beépített típusok mérete, helyfoglalása nyelvi szinten definiált, nem függ a programot futtató gép architektúrájától. A karakterek tárolásánál a nemzetközileg elfogadott, 16 bites Unicode-ot használják.
static final int SMTPport = 25;
A Jávában nincs #define, sem a C++ const-ja, ennek a legközelebbi megfelelôje a final változó, a fordítóprogram gondoskodik róla, hogy ennek értéke ne változhasson meg. Látható, hogy a változó deklarációjával együtt kezdeti értéket is adhatunk neki, ez persze final változó esetén kötelezô.
A static módosító egyelôre ne zavarjon bennünket, pontos jelentésére majd az osztályok ismertetésénél térünk ki. Elöljáróban csak annyit, hogy ezek azonosak a C++-ból ismert osztályváltozókkal és ezek közelítik meg leginkább a szokásos nyelvek globális változóit.
A beépített numerikus típusokon a C-bôl jól ismert mûveletek értelmezettek. Az numerikus típusú értékekkel a szokásos aritmetikai mûveletek használhatók. Az egész típusú értékekre használható bit mûveletek kiegészültek a >>> operátorral, amely jobbra léptetésnél 0-t és nem az elôjelet lépteti be a legnagyobb helyiértékû bitre. Ezek az operátorok értékadással is kombinálhatók, pl.: +=, /=, ...
A logikai értékek a C-vel ellentétben nem egész típusúak. Azonos típusú értékek összehasonlítására használt operátorok logikai értéket állítanak elô, ilyen értékekre használhatók az ismert logikai mûveletek is.
A következô táblázat tartalmazza a Jáva nyelv összes operátorát - némelyikrôl egyelôre nem beszéltem - precedenciájuk csökkenô sorrendjében:
| () [] . | zárójelek, indexelés, osztály komponensére hivatkozás |
| ++ -- ! ~ instanceof |
(pre- vagy poszt-) inkremens és dekremens, logikai és bitenkénti negálás, típus ellenôrzés |
| new (type)expression | új egyed létrehozása |
| * / % | szorzás, osztás, moduló |
| + - | összeadás, kivonás |
| << >> >>> | bitenkénti léptetések |
| < > >= <= | összehasonlítások |
| == != | egyenlô, nem egyenlô |
| & | bitenkénti AND |
| ^ | bitenkénti XOR |
| | | bitenkénti OR |
| && | logikai AND |
| || | logikai OR |
| ? : | feltételes kifejezés |
| = += -= *= /= %= ^= &= |= <<= >>= >>>= |
különbözô értékadások |
Az egyszerû, beépített típusokon túl a Jáva csak kétfajta összetett adattípust tartalmaz, a programozók által definiálható osztályokat (class) illetve a tömböket (array), amelyek egyébként teljes értékû osztályok. Nincs struct, union, de nincs typedef sem, sôt mutatók (pointer) sincsenek!
static Socket smtpconn; static DataInputStream instream; static DataOutputStream outstream;
A fenti 3 sor a szabványos Jáva könyvtárakban definiált osztályok - Socket, DataInputStream, DataOutputStream - egy-egy példányának, egyedének (objektum) foglal helyet, pontosabban ezek egyelôre csak üres hivatkozások, az objektumok még nem jöttek létre.
// Program: drótposta címek ellenôrzése SMTP kiszolgáló segítségével // Használata: // java SMTPclient <host> <user>
A Jáva örökölte a C-bôl a /* ... */ stílusú megjegyzés szintaxist, a C++-ból a //-val kezdôdô egysoros megjegyzéseket, végül a /** ... */ alakú megjegyzések a kiegészítô dokumentációs rendszerrel (javadoc) együtt használhatók.
Minden Jáva alkalmazásnak, pontosabban az egyik osztályának - mivel a Jávában minden utasítás csak osztályok definíciójában szerepelhet - tartalmaznia kell egy main nevû, itt következô fejlécû függvényt:
public static void main (String args[])
{
A public a módszer láthatóságáról nyilatkozik, jelentése: bárhonnan meghívható. A static jelentésérôl egyelôre annyit, hogy az eljárás csak osztályváltozót használ, void a módszer visszatérési értékének típusa: nem ad vissza értéket.
A Jáva alkalmazás futtatását a virtuális gép a main eljárás végrehajtásával kezdi A main eljárás paramétere egy szövegtömb, amelynek egyes elemei a parancssorban megadott argumentumokat tartalmazzák. A szövegek tárolására, kezelésére szolgáló String egy elôre definiált osztály, nem pedig karaktertömb, mint a C-ben. A tömbök indexértékei itt is nullától kezdôdnek, viszont itt az args[0] nem a program nevét adja vissza, mint a C-ben, hanem ténylegesen az elsô argumentum. Akinek hiányzik a megszokott argc argumentumok száma paraméter, ne aggódjon, a Jáva tömbök méretét futás közben is le lehet kérdezni.
Az egyes eljárásokban természetesen használhatunk lokális változókat, itt a String osztály egyedére lesz szükségünk, amelyet deklarációjával egyidejûleg a new parancs segítségével létre is hozzuk.
String res = new String();
Lokális változókat a módszerek törzsében tetszôleges helyen deklarálhatunk, sôt az egyes programblokkok - { ... } - saját, máshonnan nem látható lokális változókkal rendelkezhetnek.
if (args.length != 2)
{
System.out.println("Usage:");
System.out.println(" java SMTPclient <host> <user>");
System.exit(1);
}
A System könyvtár a Jáva programok futtatásához szükséges objektumokat, módszereket tartalmazza. Ilyen a programok szabványos kimenetét (standard output) - pl. konzol periféria - megvalósító out objektum. A kiíró eljárás a print illetve println, amelynek csak egyetlen paramétere van, de elég "intelligens" ahhoz, hogy karakteres formában tetszôleges típusú értéket (igen, még a felhasználó által definiált objektumokét is) "megjelenítsen". A programunkban csak szövegek kiíratására fogjuk használni. A println módszer a paraméterének kiírása után még egy új sort is kiír.
A programból vagy a main módszer befejezésével, vagy a System könyvtár exit módszerének meghívásával lehet kilépni.
A Jáva nyelv átvette a C vezérlési szerkezeteit, az elágazásokhoz az if-else és switch; ismétlésekre, ciklusszervezésre a for, while és do-while utasítások használhatók. Eltérés, hogy az összes feltételnek logikai értéknek kell lennie, int nem használható, ezért a fordítóprogram kiszûri a C programozók "kedvenc" hibáját, amikor if-ben értékadást ("=") írunk egyenlôség-vizsgálat ("==") helyett.
A nyelvbôl kimaradt az ugró utasítás (goto), de megmaradtak a címkék (label). A címkéket ciklusutasítások megjelölésére használhatjuk, így a ciklus törzsében kiadott break és continue utasítások nem csak a legbelsô, hanem bármelyik, címkével ellátott beágyazó ciklusra hivatkozhatnak.
A tisztességesen megírt C programok legnagyobb problémáját az egyes eljárások végrehajtása közben esetleg elôbukkanó hibák, ún. kivételek (exception) lekezelése jelenti. Kisebb gondossággal megírt programoknál a programozó hajlamos elfeledkezni arról, hogy legtöbbször az eljárás visszatérési értékének tesztelésével ellenôrizze, sikerült-e a végrehajtott mûvelet. Ha mégis megteszi, leggyakrabban egyszerûen befejezi a programot, olyan bonyolult a hiba elôbukkanását és okát "felfelé" terjeszteni és a megfelelô helyen lekezelni azt. Ezen segíthetnek a fenti utasítások. Most csak a felületesen ismerkedhetünk meg a kivételkezelés rejtelmeivel, majd késôbb részletesen visszatérünk a témához.
try
{
Egy try blokkba zárt utasításcsoporton belül bárhol elôforduló kivétel hatására a program normális futása abbamarad és a vezérlés automatikusan a catch blokkra kerül. Itt a catch paramétereként megkapjuk a hiba okát - általában egy Exception típusú objektumot -, aztán kezdjünk vele, amit tudunk. A példaprogramunk egyszerûen kiírja a hiba okát. A programozó maga is definiálhat ilyen kivételeket, amiket - no meg az egyes catch blokkokban lekezelhetetlen kivételeket - a throw utasítással felfele passzolhatunk, amíg valaki - legrosszabb esetben a virtuális gép - "lekezeli".
openSMTPconnection(args[0]);
Elküldünk egy HELO üzenetet, hozzáfûzve a saját gépünk nevét (részletekrôl majd máskor), a visszakapott választ (res tartalma) nem használjuk.
res = sendMessage("HELO " +
java.net.InetAddress.getLocalHost().getHostName());
Elküldünk egy VRFY üzenetet a második argumentumként megkapott felhasználó nevével. A visszakapott választ kiírjuk.
res = sendMessage("VRFY " + args[1]);
System.out.println(res);
Elküldjük a búcsúzó QUIT üzenetet és lezárjuk a kapcsolatot.
res = sendMessage("QUIT");
closeSMTPconnection();
}
Bármi hiba történt, kiírjuk a program kimenetre.
catch(Exception e)
{
System.out.println("Error: " + e.toString());
}
};
Egész egyszerû, nemde? Persze csaltam, azért ilyen egyszerû minden, mert "magasszintû", a feladathoz alkalmazkodó eljárásokat használtam. Ezeket még definiálni kell, mert sajnos nem szerepelnek a Jáva könyvtárakban.
static void openSMTPconnection (String host) throws IOException
{
Persze a korábban megismert kivételkezelés belezavar a képbe: a Jáva nyelv megköveteli, hogy a módszerekben elôforduló kivételeket vagy le kell kezelni, vagy deklarálni kell, hogy lekezeletlenül továbbadjuk. A módszer fejében a throws parancs erre szolgál. (Megjegyzés: a lekezeletlen kivételek deklarálásának szabálya alól is vannak "kivételek", de errôl is csak késôbb.)
Elôször létrehozunk egy új Socket-et, egyben megnyitva az összeköttetést a paraméterként megkapott gép 25-ös (SMTP kiszolgáló) kapujával (port).
smtpconn = new Socket(host, SMTPport);
Az átvitelre két - input és output - stream objektum szolgál, amelyeket a get...Stream eljárással kibányászunk a kapcsolatból.
instream = new DataInputStream(smtpconn.getInputStream());
outstream = new DataOutputStream(smtpconn.getOutputStream());
Ezen stream-ek segítségével már közvetlenül olvashatunk vagy írhatunk a kiépült kapcsolaton. Itt az elsô beérkezô sort - az SMTP kiszolgáló bejelentkezô üzenetét - egyszerûen eldobjuk.
String dummy = instream.readLine();
};
A kapcsolat lezárása egyszerû:
static void closeSMTPconnection () throws IOException
{
smtpconn.close();
};
Egy SMTP üzenet kiküldéséhez egy kicsit ügyeskednünk kell:
static String sendMessage(String msg) throws IOException
{
Elôször is a kiküldendô üzenetet - a String típusú msg paramétert - Byte-okká alakítva kell elküldeni. Ne feledjük el, hogy a Jáva a karakterek tárolására - és egy szöveg is ezekbôl áll - 16 Bites Unicode-ot használ, a szegény SMTP kiszolgáló alaposan meg lenne lepve, ha ezt kapná. A Byte-sorozat végére még odabiggyesztjük a protokoll által megkívánt CR és LF karaktereket. Legalább látunk arra is példát, hogyan lehet - úgy, mint a C-ben - karakter konstansokat megadni.
outstream.writeBytes(msg);
outstream.write('\015'); outstream.write('\012');
A flush utasítás kiüríti az átviteli puffert, elküldi az összegyûlt Byte-okat az összeköttetésen.
outstream.flush();
Az SMTP szerver egy ilyen üzenetet nem hagy válasz nélkül, az egy soros választ beolvassuk és visszaadjuk a módszert meghívó programnak. Az utasítás arra is példa, hogy egy változót (res) nem csak a módszerek elején, hanem bárhol deklarálhatunk, ahol Jáva utasítás állhat.
String result = instream.readLine();
return result;
};
}
javac SMTPclient.java
paranccsal lehet. Ha nem követtünk el gépelési hibát és a Jáva Fejlesztôi Környezetet (JDK) is helyesen telepítettük, akkor a fordító létrehoz egy SMTPclient.class állományt, ami a lefordított Byte kódot tartalmazza. Az állomány neve nem a forrás nevébôl származik, hanem az állományban definiált osztály nevét hordozza. Ha több osztályt definiálnánk, a fordító több különálló állományt hozna létre.
A programunkat tesztelhetjük például a
java SMTPclient hapci.mmt.bme.hu kiss
paranccsal és kis szerencsével a válasz:
250 Kiss Istvan <kiss>
lesz, aki pedig én vagyok!
Az objektumorientáltság még elég új elv ahhoz, hogy a teoretikusok felhevült hitvitákban próbálják definiálni lényeges vonásait. A teljesség igénye nélkül én itt az egyik széles körben használt definíciót ismertetném, természetesen olyat, amely illik a Jávára. Ezek szerint:
Általában csak az elsô három követelménynek eleget tevô programozási nyelvet, technológiát objektum-alapúnak (object based), míg a negyedikkel kiegészülôket objektumorientáltnak (object-oriented) hívják. Az elsô 3 építôelem már korábbi programozási nyelvekben is megjelent, ezt leggyakrabban absztrakt adattípusoknak nevezték. Kezdetben én is ezzel foglalkozom.
A Jávában minden egyes objektumnak meghatározott típusa kell, hogy legyen, azaz valamelyik osztályba kell tartoznia. Az objektumokra változókon keresztül hivatkozhatunk, pl. a
Person somebody;
azt jelenti, hogy a somebody név mindig egy Person típusú objektumra hivatkozik. Viszont a C++ nyelvvel ellentétben a fenti deklaráció nem jelenti egy új objektum létrejöttét, a változó egyelôre nem hivatkozik semmire, azaz "értéke" null. A
Person somebody = new Person("Kovacs", "Istvan", "15502280234");
utasítás nem csak definiál egy új változót, de a new paranccsal létre is hoz egy új objektumot, amelyre a változó hivatkozik.
Nagyon fontos megértenünk azt, hogy a Jávában minden változó hivatkozást tartalmaz csupán. Ezt szem elôtt tartva érthetô, hogy az értékadás (=) operátor nem készít másolatot, a bal oldali változó ugyanarra az objektumra hivatkozik majd, mint a jobb oldal. Ha valakinek mégis másolatra van szüksége, többnyire használhatja a csaknem minden osztályban megtalálható clone módszert. Hasonlóképpen az egyenlôség vizsgálatának C-bôl ismert operátora (==) is a referenciák egyenlôségét ellenôrzi, az objektumok strukturális ellenôrzésére az equal módszer való, már amennyiben létezik ilyen.
Ha már minden objektumra amúgy is csak referenciákon keresztül hivatkozhatunk - természetesen a hivatkozás feloldásának mûveletét (dereference) nem kell külön kiírnunk -, már nem is tûnik túl meglepônek, hogy a Jáva külön mutató típust nem tartalmaz. Ez nagyon sok programozási hibától, biztonsági problémától megkímél bennünket. A referenciák viszont szentek és sérthetetlenek, semmiféle mûvelet, konverzió nem végezhetô rajtuk.
Az egyes referenciák által hivatkozott objektumok típusát az instanceof logikai értéket adó operátorral tudjuk lekérdezni, például
if (x instanceof Person) then System.out.println("x egy személy!");
Azt már láttuk, hogy új objektumokat a new utasítással lehet létrehozni, megszüntetni, törölni viszont nem kell. A Jáva virtuális gép, amely a programokat futtatja, tartalmaz egy szemétgyûjtô (garbage collection, gc) - jelenleg az ún. mark-and-sweep típusú - algoritmust, amely általában a háttérben, a CPU szabadidejében, a programmal aszinkron futva összegyûjti a már nem hivatkozott objektumokat és azok tárterületét felszabadítja, hogy a new újra felhasználhassa majd. A szemétgyûjtés teljesen rejtetten, automatikusan történik, a programozóknak általában nem is kell törôdniük a szemétgyûjtéssel.
Ha már vannak objektumaink, nézzük meg, hogyan tudunk hatni rájuk. Az egyes objektumok módszereit az
obj.method(parameter, parameter, ...)
szintaxissal hívhatjuk meg. Az objektumorientált terminológia ezt gyakran üzenetküldésnek (message passing) nevezi, pl. a
somebody.changePID("15502280234");
utasítás "megkéri" a somebody objektumot, hogy hajtsa végre saját magán a changePID mûveletet a "15502280234" paraméterrel. Az ilyen módszerhívások vezethetnek az objektum belsô állapotának, azaz belsô változói értékének megváltozásához is, de gyakran csak egy belsô változó értékének lekérdezése a cél.
Bár a tiszta objektumorientált elvek szerint egy objektum belsô állapotváltozóinak értékéhez csak módszerein keresztül lehetne hozzáférni, a Jáva - a C++-hoz hasonlóan - megengedi a programozónak, hogy bizonyos változókat közvetlenül is elérhetôvé tegyen. Pl. amennyiben age közvetlenül látható a
somebody.age = 46;
utasítás közvetlenül a példaszemélyünk életkorát változtathatja meg.
class ClassName { /* az osztály törzse */ }
programszerkezettel definiálhatnak, ahol a ClassName az újonnan definiált osztály neve lesz, az objektumok belsô állapotát és viselkedését pedig a kapcsos zárójelek közötti programrészlet írja le. A class alapszó elôtt, illetve az osztály neve után opcionálisan állhatnak még különbözô módosítók, de ezekrôl majd késôbb.
class Person
{
String name, surname, pid;
byte age;
Person mother, father;
A képzeletbeli Person típusunkba tartozó egyedek három szövegváltozóban tárolhatják a személy vezeték- és keresztnevét, személyi számát (ez persze lehetne akár egy long egész szám is), egy Byte-ban az életkorát és két Person típusú változóban az apját és anyját. Az utolsó 2 változó példa arra, hogy egy egyed belsô állapota hivatkozhat más - akár az egyeddel megegyezô típusú - objektumokra is.
void changePID (String newPID) throws WrongPIDException
{
if (correctPID(newPID)) pid = newPID
else throw new WrongPIDException();
}
Mint látjuk, az egyes módszereknek lehet visszatérési értéke - bár a példánkban nincsen, ezt jelzi az ilyenkor kötelezô void -, illetve adott típusú és számú bemenô paramétere. A módszer nevét, visszatérési értékének és paramétereinek számát, típusát a módszer lenyomatának (signature) nevezzük.
A módszerek meghívásánál a lenyomatban definiált formális paraméterek aktuális értéket kapnak. A Jávában minden paraméterátadás érték szerint történik, azaz a paraméter helyén szereplô értékrôl másolat készül, a módszer ezt a másolatot látja, használja. Persze, ha a másolat módosul, az az eredeti értéket nem érinti. Kicsit becsapós a "mindig érték szerinti paraméterátadás" szabálya. Amennyiben a paraméter nem valamelyik beépített, egyszerû típusba tartozik, úgy az átadásnál a referenciáról készül másolat, azaz a C++ fogalmai szerint ilyenkor referencia szerinti átadás történik, tehát a hivatkozott objektum a módszer belsejében megváltoztatható. A visszatérési érték sem feltétlenül egy egyszerû típusba tartozó érték, hanem lehet objektum referencia is.
Az osztály belsejében azonos névvel, de egyébként különbözô lenyomattal több módszert definiálhatunk (többes jelentés, overloading), ilyenkor a fordító a módszer hívásánál a paraméterek számából és típusából dönti el, hogy melyik módszert akarjuk meghívni, de a kiválasztásnál a módszer visszatérési értékének típusát a fordító nem veszi figyelembe.
A módszerek törzsében a korábban már megismert utasításokat írhatjuk. A kifejezésekben, értékadások bal oldalán használhatjuk az eljárás paramétereit, lokális változóit, de az objektum egyedváltozóinak értékét is. Amennyiben a saját objektumra akarunk hivatkozni, úgy használhatjuk a this szimbólumot. Pl. a pid = newPID azonos a this.pid = newPID utasítással.
A módszerek fejében használhatjuk a native módosítót, ez a fordítóprogramnak azt jelenti, hogy a módszer törzsét nem Jávában írtuk meg, hanem az aktuális platformtól függô módon, pl. C-ben. Az ilyen módszerek paraméterátadási módja, esetleg az elnevezési konvenciói az aktuális platformtól függhetnek. Természetesen ilyenkor az osztálydefinícióban a módszernek csak a lenyomatát kell megadni. Az ilyen módszereket használó programok sajnos elvesztik a Jáva programok architektúra-függetlenségét, de egyébként a native módszerek mind a láthatóság, mind az öröklôdés szempontjából a többi módszerrel teljesen azonos módon viselkednek.
Person () { /* üres */ };
Person (String name, String surname, String PID)
{
this(); // az üres konstruktor egyenlôre nem csinál semmit
this.name = name; this.surname = surname; this.PID = PID;
...
};
A konstruktorokat a new utasítás kiadása hívja meg, a konstruktorok közül a new-nál megadott paraméterek száma és típusa szerint választunk. Kitüntetett szerepû a paraméter nélküli, ún. alap (default) konstruktor, ha mi nem definiáltunk ilyet, a Jáva fordító automatikusan készít egyet az osztályhoz. Az így generált konstruktor a helyfoglaláson kívül nem csinál semmit.
A szemétgyûjtés miatt a C++-ból ismert destruktorok itt nem léteznek, viszont ha egy objektum végleges megszûntetése elôtt valami rendrakó tevékenység végrehajtására lenne szükség, akkor ezt írjuk egy void finalize() lenyomatú módszer törzsébe, a Jáva virtuális gép biztosan végrehajtja, mielôtt az objektum területét a szemétgyûjtô felszabadítaná, azonban az aszinkron szemétgyûjtés miatt azt soha nem tudhatjuk biztosan, hogy ez mikor következik be.
A csak statikus változókat használó módszerek a statikus, avagy osztálymódszerek. Egészítsük ki a személy példánkat úgy, hogy minden új személy kapjon egy egyedi sorszámot:
class Person
{
...
int index; // egyedi sorszám
static int counter; // létrejött személyek számlálója
static { counter = 0; } // statikus változó kezdeti értéke
Person () { index = counter++; }
// a konstruktorban használjuk fel a számlálót
static int howManyPersons () { return counter; )
...
}
A példában látható egy ún. statikus inicializáló programrészlet is - a
static { ... } -, amely utasításai az osztály betöltésénél, az esetleges
statikus változók kezdeti értékadásával egyidejûleg hajtódnak végre.
Megjegyzés: a példában ez kihagyható lenne, helyette elég lenne
static int counter = 0; // létrejött személyek számlálójaváltozódeklarációt írni.
int a[] = new int[10]; int[] a = new int[10];
Mint a többi objektumnál, a név itt is csak egy referencia, a tömb deklarációja után azt a new paranccsal létre is kell hozni. Az indexelés mûvelete azonos a C-ben megismerttel, itt is 0 a legkisebb index. Lényeges különbség viszont, hogy a virtuális gép ellenôrzi, hogy ne nyúljunk túl a tömb határán; kivétel keletkezik, ha mégis megtesszük. Minden tömb objektumnak van egy length nevû egyedváltozója, amely a tömb aktuális méretét adja vissza. Ez azért is fontos, mert a program futása során ugyanaz a tömbváltozó más és más méretû tömbökre hivatkozhat.
Természetesen nem csak a beépített, egyszerû típusokból képezhetünk tömböket, hanem tetszôleges típusból, beleértve egyéb tömböket. A Jáva többdimenziós tömbjei is mint tömbök tömbje jönnek létre. Például
int a[][] = new int[10][3]; system.out.println(a.length); // 10-et ír ki system.out.println(a[0].length); // 3-at ír ki
Még egy érdekesség: a referenciák használatának következménye, hogy nem csak "négyszögletes" kétdimenziós tömböt lehet készíteni, de olyat is, ahol az egyes sorok nem azonos hosszúak. Pl. egy "háromszög alakú tömb" létrehozása:
float f [][] = new float [10][]; for (int i = 0; i < 10; i++) f[i] = new float [i + 1];
String reverse (String source)
{
int i, len = source.length();
StringBuffer dest = new StringBuffer(len);
for (i = len - 1; i >= 0; i--) dest.append(source.charAt(i));
return dest.toString();
}
package mmt.networking.snmp
A pakkoknak programozási konvenciók szerint általában több komponensû, ponttal elválasztott nevet adunk, a fordító a névnek megfelelô könyvtár-hierarchiába helyezi el a lefordított osztályokat. Létezik egy név nélküli pakk arra az esetre, ha nem adtuk meg a package utasítást.
Az így létrehozott pakkokból lehet a múltkor megismert import utasítással egy vagy több osztályt átvenni, használni. A Jáva nyelvi környezet jelenleg a következô pakkokat tartalmazza:
| java.applet | Programkák környezete |
| java.awt | Ablakozó rendszer (Abstract Windowing Toolkit), grafikus és kezelôi felület elemek |
| java.awt.image java.awt.peer |
segéd osztályok az AWT-hez |
| java.io | be- és kivitel |
| java.lang | nyelvi szinten definiált osztályok |
| java.net | hálózatkezelés |
| java.util | segéd osztályok |
Osztályokra csak a nyilvános vagy a baráti hozzáférés vonatkozhat: nyilvános osztályokat a programunkban bárhol használhatunk, bármelyik pakkunkba importálhatjuk. Baráti osztályokat csak az adott pakkon belül lehet használni.
Egyed- illetve osztályváltozókra, módszerekre a nyilvános és baráti hozzáférés a fentivel azonos jelentésû, ezen túl a magán változók, módszerek csak az adott osztályon belül láthatók.
class Child extends Parent { /* Child törzse */ }
Az így módon megadott, ún. leszármazott osztály (Child) örökli a szülôje (Parent) tulajdonságait, azaz a belsô állapotát leíró adatszerkezetét és a viselkedést megvalósító módszereit. Természetesen az osztály törzsében ezt tovább bôvítheti, a viselkedését módosíthatja, ezt sugallja az extends (kiterjeszt) kifejezés a definíciónál.
A Jáva a C++-szal ellentétben csak az ún. egyszeres öröklôdést engedélyezi, azaz minden osztálynak egyetlen közvetlen szülôje lehet. Tulajdonképpen nem csak lehet, de mindig van is szülôje, a nyelv ugyanis definiál egy beépített Object nevû osztályt, amennyiben az új osztály definíciójában máshogy nem rendelkezünk, automatikusan "extends Object" értendô, azaz minden osztály közvetlenül vagy közvetve, de örökli az Object-ben definiáltakat. Az így örökölt módszerek például az egyes objektumok másolásával (clone), összehasonlításával (equals), megnevezésével (toString), illetve osztálya megkülönböztetésével (getClass), vagy a többszálú futtatással (pl. wait, notify) kapcsolatosak.
Szükség esetén a meglévô osztályainkból való leszármaztatást megtilthatjuk úgy, hogy azt "final class"-ként definiáljuk. Ezt akkor alkalmazzuk, ha nem akarjuk, hogy egy mások által belôle leszármaztatott osztály nem kívánt módon módosítson az osztályunkban definiált viselkedést.
A szülô módszerei is öröklôdnek, egy leszármazott osztályban használható a szülô bármelyik nyilvános, védett vagy baráti módszere. Azonban a módszerek esetében nagyobb szabadságunk van: ha a leszármazottban a szülôben meglévô módszerrel azonos lenyomatú módszert definiálunk, az elfedi a szülôbeli jelentést, így megváltoztatva egy a szülôben definiált viselkedést. A módszerek ilyen jelentésének megváltoztatását megakadályozhatjuk, ha azt a szülôben finalnak definiáljuk.
Láttuk, hogy egy módszerben a saját egyedváltozókra a this referencia segítségével hivatkozhatunk, öröklôdés esetén a szülôbôl örökölt egyedváltozókra, módszerekre hivatkozásnál a super referenciát használhatjuk.
Persze az új osztályban láthatók lehetnek a szülô osztályváltozói és az ezeket kezelô statikus módszerek is, ez azonban nem öröklés, hanem inkább kölcsönös használat, hiszen minden statikus változóból és módszerbôl továbbra is csak egy van.
Nem öröklôdnek a konstruktorok, minden osztályhoz meg kell írni a saját konstruktorait. Ebbôl a fordító csak az alap - paraméter nélküli - konstruktort hajlandó automatikusan létrehozni, amely úgy mûködik, hogy miután a tárban a kazalon (heap) az egyed számára helyet foglalt, lehívja a szülô alapkonstruktorát, a super()-t. Egy leszármazott-béli konstruktor ezt a szülô alapkonstruktorát mindig automatikusan meghívja, hacsak a leszármazott konstruktorában valamely más paraméterezésû super(...) konstruktort a saját konstruktorának elsô utasításaként meg nem hív.
Végezetül az öröklôdésben érdekes szerep jut az abstract módosítóval deklarált módszereknek, olyan módszereknek, amelyeknek egy osztály csak a fejét (lenyomatát) definiálja, de a törzse helyét kihagyja. Az ilyen absztrakt módszereket valamelyik leszármazott osztálynak kell majd definiálnia. Legalább egy absztrakt - saját maga által absztraktnak definiált, vagy így örökölt és nem konkretizált - módszerrel rendelkezô osztályt absztrakt osztálynak nevezünk, ezt az osztály fejében a class elôtti abstract módosítóval kell, hogy jelezzük. Az absztrakt osztályok sajátossága, hogy nem lehetnek egyedei, a fordító hibaüzenettel visszautasítja a new utasítást.
Ez persze csak akkor izgalmas, ha a program szövegébôl nem látszik konkrétan, hogy éppen milyen típusú elemmel van dolgunk. Ez egy szigorúan típusos nyelvnél, mint a Jáva, csak úgy lehet, ha bizonyos lazításokat vezetünk be, pl. megengedjük, hogy egy szülô típusú referencia aktuálisan hivatkozhat valamelyik leszármazott típusra is.
Definiáljuk például a jól ismert vicc nyomán a példabeli Person osztályunkban egy absztrakt SqueezeToothPaste nevû módszert a fogpaszta tubusból kinyomására.
class Person { ... void SqueezeToothPaste(); ... }
Származtassuk le a férfi és a nô osztályokat a személybôl, ezekben már megadva konkrétan, hogyan is szokták a férfiak és a nôk a fogkrémes tubust megnyomni:
class Man extends Person
{
void SqueezeToothPaste() { /* ... tekerd az egyik végérôl kezdve ... */ };
}
class Woman extends Person
{
void SqueezeToothPaste() { /* ... markold középen és nyomjad ... */ };
}
Ezek után képezhetünk egy tömböt, amely egyes elemei hol Man, hol Woman típusúak lehetnek
Person[] p = new Person [20]; p[1] = new Man(); p[2] = new Woman(); ...
A programban elôforduló p[n].SqueezeToothPaste() módszerhívásról a fordítóprogram még nem tudja eldönteni, a hogy p adott indexû helyén épp férfival, avagy nôvel akadt dolga. Ez csak a konkrét futáskor derül ki, akkor kell majd kiválasztani a két SqueezeToothPaste() közül az alkalmazandót. C++ programozók figyelem: ott ezt a mûködést virtuális függvényhívásnak hívják és minden esetben külön kell a programban deklarálni. A Jávában minden módszer virtuális!
A példa azt is illusztrálja, hogy egy szülô típusú referencia esetén használhatunk minden további nélkül gyerek típusra hivatkozást. Egyébként itt is ismert a típus átformálás (type casting) fogalma, de itt kötöttebb mint a C++-ban, mert
Ennek nagy haszna, hogy az öröklôdési hierarchiában nem rokon osztályok is viselkedhetnek hasonlóan, az objektumorientált terminológia szerint azonos protokoll - a módszergyûjtemény - segítségével kommunikálnak.
Ha egy osztály megvalósít egy interfészt, azt a
class A implements I { ... }
formában lehet kifejezni, de ennek az a következménye, hogy A-ban az összes I-beli módszert meg kell valósítani. A Jávában többszörös öröklés ugyan nincs, de egy osztály egyidejûleg több interfészt is megvalósíthat.
Egyébként az interfészben deklarált minden módszer nyilvánosnak és absztraktnak tekintendô, de a módosítókat - sem ezeket, sem másokat - nem lehet kiírni. Szükség esetén egy interfész deklarálhat változókat is, ám ezek mind véglegesek, nyilvános és statikusak (final public static) és természetesen értéküket azonnal iniciálni kell.
Persze a fenti feladatot meg lehetne úgy is írni, hogy egy kicsit rajzolunk, majd egy kicsit az egérrel foglalkozunk, és így tovább, de ez elég macerás, különösen azért, mivel egy igazi programnál sok egyéb eseményre is figyelnünk kellene. Jó lenne, ha a programozási nyelvünk - és az alatta rejtôzô operációs rendszer - segítene bennünket, lehetôvé tenné, hogy a programunk egyidejüleg több tevékenységgel is foglalkozzon, és ezek összehangolásával lehetôleg ne kelljen sokat törôdni. Így merül fel a párhuzamos programrészletek használatának igénye. Jó elôre érdemes kiemelni, hogy még napjainkban is a legtöbb számítógép egyetlen processzort tartalmaz, ezért igazi párhuzamos, egyidejûleg mûködô tevékenységrôl nem beszélhetünk.
Talán kicsit jogosulatlanul használtam a "régivágású" jelzôt, sokan azért írnak egyetlen szálon futó programokat, mert nincs egyéb magasszintû eszköz a kezükben, igazán nagy feladatatokat pedig kinek van kedve gépi kódban megírni.
A párhuzamosan futó tevékenységek elôször az operációs rendszereknél jelentkeztek, a multiprogramozáshoz elengedhetetlen, hogy amíg egy program (folyamat, process) pl. valamilyen lassú perifériás átvitelre várakozik, a rendszer más programot is futtathasson legalább egy rövid ideig. Az operációs rendszerek ezt a lehetôséget megnyitották a rendszerközeli programozók számára is, például ilyen célokat szolgál a UNIX rendszerek fork() rendszerhívása. Ezt már lehet pl. C nyelvû programokból használni, de lassan-lassan megjelentek magasabbszintû programozási nyelvek (Ada, Modula-2, ...), amelyek nyelvi absztrakcióikban igyekeztek a párhuzamos programozás "piszkos" részleteit mind jobban elrejteni a programozók elôl.
A szál (thread) viszonylag új fogalom, a szálak és a folyamatok közötti különbségek megértését segíti, ha megismerjük a szálakra használt másik elnevezést: pehelysúlyú folyamat (lightweight process). Míg egy fork-kal létrehozott tevékenység egészen önálló életet él, saját tárterülettel rendelkezik, amelyre a rendszer féltékenyen vigyáz, addig a szálak közös tárterületet, állományokat és egyéb rendszer-erôforrásokat használnak, csak a vermük és a regisztereik a sajátjuk. A közös erôforrások tulajdonosa általában egy folyamat, a szálak ennek a környezetében (context) futnak.
Ha vannak folyamataink, miért kellenek a szálak? Gyorsabban lehet közöttük váltogatni, a várakozó tevékenység gyorsabban felébredhet, reagálhat valamilyen eseményre. A közös memória megkönnyíti az tevékenységek közötti információcserét is. Persze az elônyök mellett a szálakkal problémák is adódhatnak: közös lónak túros a háta, a közös tárban turkálásnál nagyon kell vigyázni arra, hogy mikor melyik szál következhet. Egy jól megtervezett nyelv, rendszer igyekszik kivédeni ezeket a hibákat, de a programozók zseniálisak, ha új programozási hibákat kell kitalálni, és sajnos a párhuzamos tevékenységekkel együtt megjelentek a rettegett idôfüggô, nem reprodukálható hibák.
Újabban divattá váltak a szálak, lassan néhány operációs rendszer - pl. a Sun Solaris 2.x rendszere, vagy a Windows NT - rendszerszinten is támogatja ezeket, de megjelentek olyan programcsomagok (pl. PThreads), amelyek segítségével a hagyományos UNIX rendszereken is használhattunk C nyelvi programokból szálakat. A Jáva nyelv túllép ezen, nyelvi szintre emeli a szálak fogalmát, használatuk támogatását.
A szálaknál is, mint az egyéb párhuzamos tevékenységnél, a következô alapvetô problémák merülnek fel:
class MyThread extends Thread
{
public int ID;
MyThread (int i) { ID = i; };
public void run ()
{ /* a szál tevékenységének leírása */ }
}
Ezek után a programunkban létrehozhatunk néhány saját szál objektumot:
MyThread first = new MyThread(1); MyThread second = new MyThread(2);
A fenti példa azt is illusztrálja, hogy a leszármazott osztály konstruktorát felhasználhatjuk arra, hogy az egyes szálaknak megszületésük elôtt egyedváltozókban olyan objektumokat adjunk át, amelyeket az egyes szálak az éltük folyamán használhatnak.
Az így létrehozott szálak még csak "megfogantak", de nem születtek meg, nem kezdték el a run módszer törzsét végrehajtani. Ehhez meg kell hívni a Thread osztályból örökölt start módszert:
first.start(); second.start();
A start módszer indítja majd el a run törzsét. Eztán már mindkét szál fut, versengve az egyetlen központi egységért. Hogy nagyobb legyen a tülekedés, a fenti kettôn túl van még néhány szál, amire talán nem gondoltunk: a fôprogram - a main statikus eljárás törzse - is egy szál, sôt a tárgazdálkodáshoz szükséges szemétgyûjtés is párhuzamos tevékenységként valósul meg.
A Thread osztálynak van még néhány konstruktora, talán említést érdemelnek azok a konstruktorok, ahol egy String paraméterben nevet is adhatunk a szálunknak, amit pl. a nyomkövetésnél jól használhatunk. Ezt felhasználva írunk egy másik konstruktort is:
class MyThread extends Thread
{
...
MyThread (int i, String name) { super(name) ; ID = i; };
...
}
MyThread first = new MyThread(1, "First");
A szálak létrehozásának a Thread-bôl leszármaztatáson túl van egy másik módja: a java.lang tartalmaz egy Runnable interfész is, amely egyetlen módszert, a run-t specifikálja. Ha a mi osztályunk implementálja a fenti interfészt, létrehozhatunk egy Thread típusú objektumot, a konstruktornak megadva az objektumunkat, amely a run-t megvalósítja. A fenti példa a rövidség kedvéért egyetlen szállal az interfészt használva így nézhet ki:
class MyObj implements Runnable
{
public int ID;
MyThread (int i) { ID = i; };
public void run ()
{ /* a szál tevékenységének leírása */ }
};
MyObj firstObj = new MyObj(1);
Thread first = new Thread(firstObj);
first.start();
Egy trükk: ha késôbb nem akarunk sem az objektumra, sem a szálra hivatkozni, azaz megelégszünk azzal, hogy az fut, az utolsó 3 sort össze is vonhatjuk:
new Thread(new MyObj(1)).start();
Melyik létrehozási módszert érdemes használni? Gyakran nincs választási lehetôségünk, mivel a Jáva nem engedélyez többszörös leszármazást, ha az osztályunkat más osztályból akarjuk leszármaztatni pl. programkát írunk, akkor csak az interfészen keresztüli definíció használható. A Thread-bôl közvetlen leszármaztatást csak akkor érdemes használni, ha valamilyen okból a Thread-bôl örökölt néhány módszert - természetesen a run-on kívül - felül akarunk definiálni.
Az egyes szálak 5 különbözô állapotban lehetnek:
Az egyes állapotátmenetek magyarázata:
Minden szál rendelkezik egy, a "fontosságát" meghatározó int számmal, amelyet örököl az ôt létrehozó száltól, de a setPriority(int newprio) hívással bármikor be is állíthatja a MIN_PRIORITY és MAX_PRIORITY közötti értékre. Azért hívják a rendszert mégis fix prioritásúnak, mivel maga a virtuális gép soha nem módosítja szálak prioritását.
A futásra kész folyamatok közül a futó kiválasztása mindig szigorúan a prioritások alapján történik, a legnagyobb, illetve az azonos prioritással rendelkezôk közül a legrégebben várakozó indul tovább. Az ütemezés azért preemptív, mert amennyiben az éppen futónál nagyobb prioritású szál válik futásra késszé, akkor a futó megszakad (6-os átmenet) és a legnagyobb prioritású indul tovább. (Megjegyzés: ez csak nagyobb prioritás esetén történik, azonosnál nem!)
Még egy ilyen preemptív ütemezés esetén is elôfordulhat, hogy a legnagyobb prioritású szál kisajátítja a virtuális gépet, ha nem kényszerül várakozni (3-as átmenet) és a yield() hívással sem mond le egy idôre a futás jogáról. Ezért használnak néhány rendszernél idôosztásos (time-slicing) ütemezést. Itt minden szál csak egy adott, maximális ideig lehet futó állapotú, ha az idôszelete letelt, a virtuális gép megszakítja és beáll a futásra készek közé, a vele azonos prioritásúak mögé. Ez gyakran nagyon kényelmes, de figyelem, gondolom az egyes architektúrákon elôbukkanó implementációs problémák elkerülése végett a nyelv nem követeli meg, hogy az ütemezés idôosztásos legyen! Ha valaki erre számít, elôfordulhat, hogy a programja néhány architektúrán nem helyesen fut. (Ennyit a híres architektúrafüggetlenségrôl! Nekem ez nagyon nem tetszik, de mit tehetnék, legfeljebb az vigasztal, hogy véleményemmel nem állok egyedül.)
Egyes szálakat a programozó a setDaemon() hívással "démonizálhat". A démonok olyan párhuzamos tevékenységek, amelyek más szálaknak nyújtanak szolgálatokat, általában végtelen ciklusban futnak, gyakran arra várva, hogy más szálak kommunikáljanak velük. A Jáva program addig fut, azaz a virtuális gép addig mûködik, amíg van a rendszerben legalább egy nem démon szál.
Mivel a szálak közös erôforrásokon - pl. a táron - osztoznak., a legfontosabb szinkronizációs probléma az ún. kölcsönös kizárás (mutual exclusion) biztosítása, azaz megoldás arra, hogy bizonyos erôforrásokat egyidejûleg csak egyetlen szál használhasson, egy másik szál pedig csak akkor férhessen hozzá, ha az elôzô már konzisztens, biztonságos állapotban hagyta.
A kölcsönös kizárás megvalósítására a Jáva a Hoare-féle monitor koncepciót követi. Minden objektum rendelkezik egy zárral (lock, monitor) és a programozó elôírhatja, hogy bizonyos módszerek végrehajtása csak akkor kezdôdhet meg, ha az objektum szabad. Ez a módszer fejében használt synchronized módosítóval történik. Az ilyen módon definiált módszer meghívása elôtt a hívó szál megpróbálja az objektumhoz - statikus módszer esetén az osztályhoz - tartozó zárat lefoglalni. Amennyiben senki nem használja a zárat, akkor elkezdi a módszer végrehajtását, természetesen ezzel kizárva az összes többi versengô szálat. Amennyiben viszont foglaltnak találja a monitort, akkor várakozni kezd. Kivételt képez az az eset, ha a monitort ugyanez a szál tartja lefoglalva, ilyenkor a futás továbbhaladhat, a Jáva monitorja újrabeléphetô (reentrant).
Miután a módszer lefutott, kilépéskor a szál felszabadítja a zárat, szükség esetén továbbindítva - futásra késszé téve - egyet a zárra várakozók közül. A programozónak külön meg kell mondania, hogy melyek azok a módszerek vagy kódrészletek, amelyek végrehajtásához kizárólagosságot kell biztosítani. (Megjegyzés: a nyelv a "szinkronizáció" fogalmát sajnos az irodalomban elterjedtnél szûkebben, a kölcsönös kizárás szinonimájaként használja. Ezentúl, bár nem tetszik, de én is követem ezt a terminológiát.)
A szinkronizált módszerhívás alternatívájaként használhatunk szinkronizált kódrészletet is, ahol a
synchronized (obj) { /* szinkronizálandó ... */ }
kódrészletet a paramétereként megadott objektum - és nem a this, mint fentebb - zárja védi. Természetesen mindkét módon a programozó felelôssége annak megállapítása, hogy melyik módszereket, kódrészletet kell védeni, az itt elkövetett hibákat a fordítóprogram nem tudja kiszûrni.
A monitor koncepcióban megvalósuló automatikus, a programozó elôl rejtett implementációjú kölcsönös kizárás sajnos az együttmûködô szálakhoz általában nem elég, kell olyan eszköz is, amelyikkel egy szál bevárhatja, amíg egy másik elér tevékenységének adott pontjára. Erre szolgál a monitor koncepciót kiegészítô, a Hoare-féle feltételes változó (conditional variable). Minden Jáva objektumhoz tartozik egy ilyen feltételes változó, amire lehet várakozni (wait()), illetve egyetlen (notify()) vagy az összes (notifyAll()) várakozót tovább lehet indítani.
Mind a wait, mind a notify módszert csak szinkronizált módszerekben lehet hívni. Wait esetén az azt kiadó szál várakozni kezd a szinkronizált objektum feltételes változójára, és ezzel együtt - ideiglenesen - felszabadítja a monitort, hogy másik módszer is futhasson. Egy szinkronizált módszerben kiadott notify kiválaszt az adott objektumra várakozó szálak közül egyet, és azt futásra késszé teszi. Mikor a monitor legközelebb felszabadul, a továbbindított szál újra megszerzi, azaz lefoglalja a monitort, és folytatja a futását.
A wait módszerben várakozó szálat csak egy notify vagy notifyAll mozdíthatja ki, de létezik a wait-nek egy paraméteres, idôzített változata is, ahol a szál legfeljebb a paraméterben millisecundum mértékegységben megadott idôtartamon keresztül várakozik. Ilyen wait-bôl felébredve a szálnak meg kell gyôzôdnie arról, hogy vajon egy notify avagy az idô lejárta miatt ébredt-e fel.
A programkák sokat profitálnak ebbôl az albérletbôl, használhatják a böngészôben meglévô teljes program-infrastruktúrát: a Web oldalból kihasíthatnak maguknak területeket, ahova rajzolhatnak, felhasználhatják a böngészô grafikus-, multimédia és pl. HTML megjelenítési szolgáltatásait, kezelôi felület elemeit, eseménykezelését, hálózati kommunikációját. Igaz, hogy lehet olyan önálló Jáva alkalmazást írni, amely egy programkának megfelelôen viselkedik, ám egy ilyen környezet felállítása viszonylag nagy munkát igényel, a programkák viszont mindent készen kapnak.
Azonban, akárcsak egy valódi albérletben, a programkák itt is korlátokba ütközhetnek. A távoli számítógéprôl óvatlanul gyakran a hálón barangoló tudta nélkül letöltött és a helyi számítógépen futni kezdô programok sokakban jogosan a vírusok rémképét idézik. Ezért a böngészô szigorúan korlátozza a felügyelete alatt futó programkákat, megakadályozza, hogy potenciálisan veszélyes tevékenységet hajtsanak végre. Így például a Jáva nyelvbe már amúgyis beépített biztonsági rendszeren, konzisztencia ellenôrzésen túl a programkák:
Sokak szerint a fenti megkötések túlságosan szigorúak, de amíg a Jáva rendszerbe nem kerülnek be a programkák módosíthatatlanságát, megbízható azonosítását lehetôvé tevô titkosítási algoritmusok - dolgoznak rajtuk -, addig nincs mit tenni, mint szigorúan kulcsra zárni az összes olyan kiskaput, ahol rosszindulatú programkák beszivárogva belerondíthatnak a számítógépünkbe.
A programka futásának vezérlésére az init, start, stop és destroy módszerek szolgálnak, valamennyien paraméter nélküliek. Az init törzse a programka letöltésekor fut le, itt végezhetôk el a kezdeti beállítások. Rögtön az init után a start is lefut, de a start módszert akkor is meghívja a böngészô, ha újra akarja indítani a programkát. A stop módszer a programka futásának leállítására szolgál. Tipikus, hogy egy HTML oldalt letöltve betöltôdnek az ott lévô programkák is, majd lehívódik ezek init és start módszere. Ha ezután böngészés közben továbblépünk errôl az oldalról, akkor az összes ott futó programka stop módszere is lehívásra kerül. Ha visszatérünk a lapra, akkor már csak a start-ok indulnak el, az init nem.
Ha a stop módszert üresen hagyjuk, a lapot elhagyva a programkánk folytathatja a mûködését, ezzel esetleg feleslegesen használva rendszer erôforrásokat. A stop-ban gondoskodhatunk róla, hogy a programka mûködése felfüggesztôdjön.
Végezetül a destroy módszer lehetôvé teszi, hogy a programka leállása elôtt felszabadítsa az összes általa lefoglalt speciális erôforrást, tisztán és rendben hagyja itt a világot. A destroy-t pl. a böngészô leállása, vagy egy futó programka újra betöltése elôtt hívja meg.
Bár a böngészôk tipikusan egy-egy szálat allokálnak a letöltött oldalon lévô minden programkához és ebbôl a szálból hívják meg a programkát vezérlô módszereket, de ez nem zárja ki, hogy a programkánk végrehajtása közben maga is létrehozzon szálakat. Szálak használata tipikus a folytonos animációt biztosító programkáknál, de célszerû a hosszú ideig tartó inicializálást - pl. nagy méretû képek hálózatról letöltését - is egy párhuzamosan futó szállal megoldani.
Ha a programka saját maga akarja kezdeményezni a rajzolást, akkor meghívja a repaint módszert, amely hatására a böngészô egy alkalmas idôpontban meghívja a programka update módszerét. Az update is az Applet-bôl öröklôdik, amennyiben nem definiáltuk újra, egyszerûen paint-et hív, de felüldefiniálva lehetôségünk van például kihasználni azt, hogy a programka már felrajzolta, amit akart, nekünk elég a meglévô képen módosítanunk.
Különösebb magyarázat nélkül közlök egy egyszerû példát, a szokásos "Hello világ" programka változatát. A programkában van egy kis csavar: képes átvenni az ôt tartalmazó lapról egy paramétert, így a "world" helyett ezt a szöveget írja majd ki, persze, ha létezik egyáltalán ilyen paraméter. A feladat egyszerûsége miatt elég csak az init-et és a paint-et definiálni.
import java.applet.Applet;
import java.awt.Graphics;
import java.awt.Font;
import java.awt.Color;
public class HelloWorldApplet extends Applet
{
Font f = new Font("TimesRoman", Font.BOLD, 36);
String name;
public void init()
{
name = getParameter("name");
if (name == null) name = "World";
name = "Hello " + name + "!";
}
public void paint(Graphics g)
{
g.setFont(f);
g.setColor(Color.red);
g.drawString(name, 5, 50);
}
}
Remélem a példám használatához szükséges, itt közölt HTML lap különösebb magyarázatok nélkül is érthetô.
<HTML> <HEAD> <TITLE>Hello!</TITLE> </HEAD> <BODY> <P> <APPLET CODE="HelloWorldApplet.class" WIDTH=300 HEIGHT=50> <PARAM NAME=name VALUE="Pisti"> Hello to whoever you are! </APPLET> </BODY> </HTML>Szeretném felhívni a figyelmet a "Hello to whoever you are!" szövegre. Az <APPLET> tag definíciója szerint annak lezárása elôtt szereplô bármilyen, nem a programka leírásához tartozó szöveget azok a böngészôk jelenítik meg, amelyek nem képesek programkák futtatására. Így ezt a példa lapot olvasva mindenki látna valamit, a szerencsésebbek nagy piros betûkkel azt, hogy
Hello Pisti!
a kevésbé szerencsések csak azt, hogy
Hello to whoever you are!
de azért ôk se csüggedjenek!
Kiss István
updated: 96/06/30, http://www.eunet.hu/infopen/cikkek/java/javaprog.htm