Java-technológia - Elméleti kérdések

Ez az oldal a korábbi SCH wikiről lett áthozva.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor, kérlek, javíts rajta egy rövid szerkesztéssel!

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót.

Minden feladat 30 pontot ér. A feladatok a tárgy weblapjáról származnak, a rövid jegyzetek pedig a kiadott diák alapján készültek, készülnek. A címsorban a kérdések vizsgákon való előfordulásának dátuma szerepel (ééhhnn).

Collections Framework, (060614)

Mutasd be a java Collections Framework-öt! Ismertesd az adatmodelleket (1.4), nevezz meg néhány implementációt, és a köztük levő különbséget. Miben változott az 1.5 java CF-je az 1.4-hez képest? Mutasd be az elvet, ahogy egy gyűjtemény elemeihez hozzáférünk. Mik az elvárások a CF-ben tárolt objektumokkal szemben? Hogyan lehet egy gyűjteményt rendezni?

!!Generikusok

List words = new ArrayList(); helyett: List<String> words = new ArrayList<String>();

!!Autoboxing-unboxing

collection-ök osztályokat tárolnak, primitív típusokat nem, tehát int helyet Integert, de a konverziót (wrapperbe csomagolás, kicsomagolás) a fordító végzi

Map<String, Integer> m =� new TreeMap<String, Integer>();�

for (String word : args) {�

 m.put(word, m.get(word) + 1);�

}

!!Új for ciklus

iterátor használata egyszerűbb, de így nem lehet törölni iterátorral, ha az is kell, azt kell használni

for (String word : args) { }

új "typesafe" enumot is kapott az 1.5

-- Main.mp9k1 - 2012.06.11.

!! iterator (5 pont)

A =Collection iterator()= metóduásval kérhetünk egy iterátort, amellyel be tudjuk járni a gyűjteményt. Van =Iterator= és =ListIterator=.

• =Iterator= metódusai: =hasNext=, =next=
• =Iterator= opcionális metódusai: =remove=
• =ListIterator= további metódusai: =hasPrevious=, =previous=, =previousIndex=, =nextIndex=
• =ListIterator= opcionális metódusai: =add=, =set=

Kivételkezelés (060522, 051219, 050111, 040112, 021218)

Írd le a Java kivételkezelés felépítését és működését. Szempontok: a kivételkezelés elve, kivételosztályok, azok hierarchiája és szerepe, ellenőrzött és nem ellenőrzött kivételek közötti különbségek, a kivételkezelés kulcsszavai és jelentésük, nyelvi konstrukciók és működésük, kivételek keletkezési módjai.

!! elv (5 pont)

Exception objektumokkal történik a hibák kezelése. Ezek a hiba helyén keletkeznek, és felfele terjednek az utasításblokkok és a híváslánc mentén, amíg valaki le nem kezeli őket, vagy ha nem kezeljük sehol, akkor megszakad a program futása.

Öröklődésnél a leszármazott osztály túlterhelt metódusa nem dobhat újabb kivételt, mint amik az ősben vannak.

!! osztályok, hierarchiájuk és szerepük (5 pont)

A kivtelek a =Throwable= osztályból származnak. =Error=, =Exception=, =RunTimeException=, +UML ábra.

=Error=: A JVM dobja, illetve API-ban használják.

Kivétel tovább dobható, illetve becsomagolható.

=printStackTrace()= metódus.

!! ellenőrzött és nem ellenőrzött különbségek (5 pont)

Ellenőrzött: az =Exception= osztályból származnak, kötelező kezelni, vagy =throws= kulcsszóval jelezni, hogy a hívó kezelje le őket.

Nem ellenőrzött: nullával való osztás és egyéb (=null= referencia, stb.) mindenhol előforduló hibákat jelezhet, de kényelmetlen és átláthatatlan lenne őket mindenhol jelezni, kezelni.

!! kulcsszavak és jelentésük (5 pont)

=throw=, =catch= (=finally=, =try=, =try-catch= blokk)

!! konstrukciók és működésük (5 pont)

=try-catch-finally= + folyamatábra

!! keletkezési módok (5 pont)

=throw= paranccsal, kifejezéskiértékelés során (nullával való osztás), metódushívás során ("kivétellel tér vissza").

Generics, generikus típusok (060201)

Ismertesd a Java 5.0-ban bevezetett generics (generikus típusok) működését. Mire szolgál, mik az előnyei a korábbi típuskezeléssel szemben. Generikus típusok definiálása, használata (ezekre mutass példát). Írd le, hogyan lehet a típusparaméterek körét szűkíteni. Mire szolgál a határozatlan típusparaméter? Hogyan valósították meg a generikus típusokat az 5.0-ás fordítóban és virtuális gépben? Ismertesd a generikus metódusok specialitásait.

Collections Framework (060120)

Mutasd be a Java Collections Framework alapjait! Mutasd be a három fő adatmodellt, és ezek jellemzőit. Említs néhány implementációt mindhárom típusra! Hogyan lehet egy Collection-t rendezni? Említs meg néhány egyéb, Collection-ökön elérhető szolgáltatást! Mire kell ügyelni többszálú alkalmazás esetén?

!! alapok (3 pont)

=java.util= alatti osztályok és interfészek, amelyek a dinamikus adatszerkezeteket és az azokat kiszolgáló interfészeket valósítják meg.

UML ábra.

• Collection
  • Set
    • SortedSet
  • List
• Map
  • SortedMap

!! list + impl (5 pont)

Lista: duplikátumok lehetnek, sorrend opcionálisan meghatározott

Implementációk: ArrayList (tömb), LinkedList (láncolt lista)

!! set +impl (5 pont)

Set: Matematikai halmaznak megfelelő, nincsenek duplikátumok, sorrend opcionális.

Implementációk: HashSet (hash tábla), TreeSet (kiegyenlített fa)

!! map +impl (5 pont)

Map (leképzés): kulcsok és értékek egyértelmű hozzárendelését határozza meg. Nem kölcsönösen egyértelmű.

Implementációk: HashMap (hash tábla), TreeMap (kiegyenlített fa)

!! sort, Comparable, Comparator (5 pont)

Természetes rendezés:

• A =Comparable= interfészt megvalósítva egy objektum saját magát tudja összehasonlítani egy másik objektummal.
• =compareTo(Object o)= metódust kell megvalósítani.

Összehasonlító osztályos rendezés:

• egy =Comparator= -ból származó objektum segítéségével történik a rendezés
• =compare(Object o1, Object o2)= metódus

Negatív, pozitív, nulla visszatérési értékek.

!! Collections szolgáltatások (4 pont)

Interfész, általános műveletek:

• =contains=
• =containsAll=
• =isEmpty=
• =iterator=
• =size=
• =toArray=

Opctionális műveletek (ha nincs megvalósítva, akkor kivételt dob):

• =add= (opcionális)
• =addAll(másikCollection)= (opcionális)
• =clear= (opcionális)
• =remove= (opcionális)
• =removeAll= (opcionális)
• =retainAll= (opcionális)

Lehetnek fix tartalmú Collection-ök is. A Collection-ök elemei csak objektumok lehetnek (wrapper class primitívek esetén).

Vannak kész algoritmusok: rendezésre, bináris keresésre, listák megfordítására, véletlen permutációk előállítására, stb.

Előállíthatóak szinkronizált nézetek, valamint módosíthatatlan nézetek is (a =Collections= statikus metódusaival).

!! nem thread safe (3 pont)

A CF megvalósításai nem szinkronizáltak.

Az =Iterator= és a =ListIterator= ún. fail-fast iterátor, ha használat közben más módosít, akkor dob egy kivételt, de ez nem garantálható.

Vannak =synchronized= kezdetű metódusok az adatszerkezetek létrehozására, de az iterátorok nem tartoznak bele, azokra külön kell figyelni.

Java I/O (060104, 031222)

Mutasd be a java I/O-t! Alapelv, legfontosabb ősosztályok. Várható kivételek, stream végének kezelése. Szűrő fogalma. Karakteres I/O, objektumos I/O. Szerializáció fogalma. További lehetőségek.

!! elv (4 pont)

Stream, adatfolyam, szekvenciális hozzáférésű. Megnyitás, írás/olvasás, lezárás. Karakteres- (=*Reader=, =*Writer=), és Bytestream (=*Stream=).

Olvashatunk/írhatunk bárhonnan/bárhova: fájl, pipe, memória, stb.

Konverzió: karakterkódolást is be lehet állítani.

Reader=, =Writer=, =InputStream=, =OutputStream

!! kivételek (3 pont)

Az EOF néhol speciális érték, máshol kivétel (=EOFException=).

IOException=, =FileNotFoundException=, =SecurityException

!! szűrők (3 pont)

Szűrő lezárása lezárja a stream-et is.

Szűrők: =BufferedReader=, =PrintWriter=, =ObjectInputStream=, =ObjectOutputStream=.

• =DataInputStream=, =DataOutputStream=: minden típushoz külön =read/write= függvény

!! karakteres i/o (4 pont)

=PrintWriter=, =PrintStream=. Karakterenként ír, a neki megadott objektum =toString= metódusának eredményét írja ki. Sorvége jelet automatikusan cseréli a platform formátumára (csak a =Writer=).

Bufferelt olvasás.

FileReader=, =FileWriter

!! objektumos i/o (5 pont)

• Objektumok közvetlen írása/olvasása.
• =ClassNotFoundException=: ha nem ismerjük a fájlban lévő osztályt.
• Beolvasásnál cast-olni kell a nekünk kellő típusra.

!! szerializáció (4 pont)

• Objektum bájtsorozattá alakítása
• =Serializable= interfész kell hozzá
• Lehet sajátot is (=writeObject=, =readObject= metódusok felülírása)
• =transient= mező nem íródik ki (titkosításhoz is jó)
• argumentum nélküli konstruktor kötelező
• Verziók! (régi verzió által kiírt objektumot az új is jól olvassa be - az objektum felelőssége, de van amit tud automatikusan kezelni)

!! további lehetőségek (típusos, módosítószók stb.) (4 pont)

• =SequenceInputStream=: Byte-os csatornák egymás után fűzhetőek
• =LineNumberStream=: olvasott sorok számát nyilvántartja
• =PushbackReader=
• =FilterReader=
• =RandomAccesFile=
• =StreamTokenizer=: szövegfeldolgozáshoz

Java biztonsági architektúra (050622)

Mutasd be a Java biztonsági architektúráját, annak fejlődését. Ismertesd a Java biztonsági architektúra alapelemeit (permission, policy, kulcsok, kulcsmenedzsment, kulcstárolás). Hogyan történik egy digitális aláírás létrehozása és ellenőrzése? A Java fejlesztői környezetben milyen, a biztonsággal kapcsolatos eszközök állnak rendelkezésünkre?

Szálkezelés (threads) (050607, 030129)

Írd le a Java szálkezelésének elemeit, működését. Mi a szinkronizáció alapja? Hogyan valósítható meg szinkronizáció metódus, illetve blokk szinten? Hogyan valósíthatunk meg szálakat? Szálak vezérlése + elavult módszerek

=Thread= osztály és leszármazottai, =Runnable= interfész, =run()= metódus.

!! monitor (8 pont)

Minden objektumhoz tartozik egy monitor, ezekkel valósul meg a szinkronizáció. A monitort egyszerre egy szál birtokolhatja - ha többnek is kell, akkor várakoznak, futásuk felfüggesztődik. Ha a birtokló elengedi, akkor a többi verseng érte, az ütemező választ.

!! synchronized metódusok (3 pont)

public synchronized void method { ... }

A metódust tartalmazó objektum monitora kell a belépéshez. Rekúrziv híváskor újra beléphet.

Statikus metódus esetén a =new MyClass.getClass()= monitorát kell megszerezni.

!! synchronized blokkok (3 pont)

synchronized (monitorobj) { ... }

Belépéskor a szál megszerzi a monitort, kilépéskor elengedi.

Atomi művelethez nem kell szinkronizáció (primitív típusok írása, olvasása, kivéve =long= és =double=).

Atomicitás: a többi szál nem láthat inkonzisztens állapotot, de nem garantál semmit, hogy másik szál mikor látja az új állapotot. Megoldás: =synchornized= mezőhozzáférés mindenhol vagy =volatile= mezők (ez garantálja, hogy az új érték azonnal láthatóvá válik a többi szál számára).

!! Thread, Runnable (5 pont)

Kivétel kimegy =stderr= -re ha nem kezeljük le.

!! notify, notifyAll, wait, join, ... (4 pont)

Ezek az =Object= osztály szolgáltatásai, kell hozzá az objektum monitora

• =wait(long timeout, long nanos)=: felfüggeszti a hívó szál futását
• =notify()=: az objektum monitorán wait()-elő szála felébresztése

Thread szolgáltatásai:

• =join(millis, nanos)=: A hívó szál várakozik, míg ez a szál be nem fejezi futását, vagy le nem jár az időkorlát (ha van).
• =sleep(millis, nanos)= felfüggeszti a futást, monitorokat nem enged el.
• =interrupt()=: alvás megszakítása
• =setDaemon(boolean)=: démon szál legyen-e

!! start, stop, suspend, resume (4 pont)

=Thread= szolgáltatásai. A =stop()= vesélyes, és a =suspend()=, =resume()= metódusokkal együtt elavult.

=stop()= esetén =ThreadDeath= kivétel bárhol a szálban, nehéz kezelni.

Java Servlet, JavaServer Pages (050523)

Írd le a Java Servlet és JavaServer Pages technológiák célját, a köztük lévő alapvető különbségeket, egymáshoz való viszonyukat! Rajzon mutasd be a servletek tipikus elhelyezkedését egy szerveren! Mutasd be a servletek életciklusát! Hogyan épül fel egy, a Java Servlet specifikációnak megfelelő web alkalmazás? Hogyan működik, és mi a célja a session kezelésnek? Mi egy tag library, és mi a célja?

Swing MVC (050126)

Írd le a Swing MVC architektúrán alapuló működési modelljét, és ennek programozási hatásait. Szempontok: koncepció, architektúrális felépítés, szálkezelés (eseménykezelés, renderelés), saját eseménykezelő rutinok írása és ezek hatása a Swing működésére, hosszan tartó műveletek összekapcsolása a grafikus felülettel.

!! koncepció (5 pont)

Pehelysúlyú komponensek, Java-ban megvalósítva, platformfüggetlen, bővebb, mint az AWT, ami az operendszer komponenseit használja. A megjelenés is egységes, J betűvel kezdődnek a komponensek nevei. Az AWT eseménykezelőjét használja.

!! MVC architektúra (5 pont)

Modell-View-Controller, adatmodell, megjelenítés, vezérlés. A Swingben a View és a Controller össze van vonva (Document-View).

LAF (look-and-feel): kinézet, minden komponenshez külön beállítható.

!! Swing-ben használt módosított MVC architektúra, ennek szinkronizálási követelménye, kölcsönös kizárás megvalósítása a renderelő és az eseménykezelő rutin között (8 pont)

Ha a képernyőfrissítés közepén megváltozik az adat, akkor inkonzisztens lehet a GUI tartalma. Ezért egy szálon történik a rajzolás és az eseménykezelés, amiből az következik, hogy a hosszú eseménykezelő műveletek blokkolhatják a GUI-t, így nem teljes a felhasználói élmény (mintha lefagyna). A hosszú műveleteket (I/O, hálózatkezelés, komplex számítások, stb.) ezért új szálon kell futtatni, majd a =javax.swing= csomag =SwingUtilities= osztályának =invoke= és =invokeLater= metódusinak átadni egy GUI-t frissítő objektumot, amit majd az eseménykezelő szál végrehajt GUI frissítés előtt.

Az eseménykezelő szálat nevezzük EDT, vagyis AWT EventDispatch Thread-nek.

Ha egy boolean adatot frissítünk, akkor azért lehet a feldolgozást végző szálból is frissíteni, de ettől bonyolultabbat nem ajánlott.

+folyamatábra.

!! invokeAndWait és invokeLater közötti különbség ismertetése (2 pont)

Az =invokeLater= után rögtön visszakapja a futást az őt hívó szál, míg az =invokeAndWait= esetében csak miután frissült a GUI.

Reflection (040126)

Írd le a Reflection fogalmát, lehetőségeit, illetve az API felépítését (fontosabb osztályok, interfészek, ezek kapcsolata). Írj le egy szituációt, amikor szükség lehet a Reflection használatára.

!! Reflection fogalma (5 pont)

Hozzáférést biztosít a program metaszintű elemeihez a programból (osztályok, metódusok, mezők, stb.)

!! osztályok, interfészek (10 pont)

=java.lang.reflect= csomag, de a =java.lang.Class= és a =java.lang.Package= osztályok is ide tartoznak.

• =Object=
  • =Array=
  • =Class=
  • =Modifier=
  • =Package=

• =AccessibleObject=
  • =Constructor= (implementálja a =Member= interfészt)
  • =Method= (implementálja a =Member= interfészt)
  • =Field= (implementálja a =Member= interfészt)

Kell egy =Class= példány, ami leírja a vizsgálandó osztályt vagy objektumot. Hozzáférés:

• =class= literás (pl.: =String.class=)
• =getClass= metódus
• =Class.forName= metódussal betöltött osztály (minősített névvel)

!! szituáció (5 pont)

• Hozzáférés privát tagokhoz valamilyen szerializációhoz hasonló szolgáltatásnál (letiltható)
• Proxy osztályok (=java.lang.reflect.Proxy=): futásidőben változtathatjuk, hogy milyen interfészt implementálnak. Az interfészekre érkező hívásokat továbbítja egy híváskezelő osztályhoz (invocation handler).
  • Az interfészek sorrendje számít, a =hashCode=, =equals= és =toString= metódusokat is továbbítja, a többi =Object= metódust nem.

Logging API (040524)

Írd le a Java Logging API elemeit és működését. Írj le egy alkalmazási példát a Logging API elemei segítségével.

Java 1.4 óta
- Logok használata:
- Hibák, kivételek jelzése a végfelhasználónak vagy a rendszergazdának

 (konfigurációs hiba, erőforráshiány, biztonsági hiba ...)

- Tesztelési fázisban a fellépő kivételek részletes leírása (+kontextus). Ezeket a

 logokat eljuttatni a fejlesztőkhöz.

- A fejlesztési fázisban hibadetektálásra, végrehajtási történet követésére,

 események bekövetkeztének ellenőrzésére.

Logger=, =Handler=, =Filter=, =Formatter

!! Működés (8 pont)

Loggereknek van szülője, neki is továbbítja az üzeneteket. Egy loggerhez több handler is tartozhat. Logolási szintek. Loggerek neve.

Handler: stream, console, file, socket, memory

!! Alkalmazási példa (4 pont)

=Logger.getLogger(String name)= metódus, aztán =logger.info=, =logger.entering=, stb. metódusok.

JNI, Java Native Interface (040608)

Írd le a Java Native Interface (JNI) célját, elemeit, eszközeit, használatának két alapvető módját. Írd le egy natív kódrészlet JNI segítségével történő integrációjának lépéseit.

!! Célja (5 pont)

Natív, rendszerközeli, platformfüggő dolgokhoz hozzáférni más nyelvekkel készült kódon keresztül, vagy más nyelvekből Java objektumok elérése. Hatékonysági okok, assembly. Java-C kommunikáció mindkét irányban, kivételek dobása-elkapása is működik.

!! Elemei (JNI API, Invocation API) (5 pont)

Natív Java metódusok (C-ben megvalósítva mondjuk), illetve az Invocation API segítségével egy Java virtuális gépet indíthatunk C-ből. Leállítani közvetlenül nem lehet, csak megkérni rá (majd leáll, ha az összes nem démon szál leállt).

!! Példa (10 pont)

A natív metódusokat a =native= kulcsszóval jelezzük, és nem írjuk meg a kódját (mintha absztrakt lenne). Ezután fordítunk, majd a =javah= programmal generálunk belőle egy C-s header fájlt, ami alapján meg tudjuk írni a C kódot. Ha ez megvan, akkor ez lefordítjuk C fordítóval, amiből kaptunk mondjuk egy DLL-t, amit a natív metódus osztályának statikus inicializátorában betölthetünk a =System.loadLibrary= metódussal. Ezután a szokásos módon használható a metódus.

Package-ek (041220, 030108)

Írd le a Java csomagok (package-ek) szerepét, tulajdonságait, használatát! (definiálásuk, hivatkozás csomagokra, hozzáférésvezérlés csomagokkal kapcsolatos kérdései, stb.)

RMI (030122)

Írd le a Remote Method Invocation (RMI) elemeit és azok szerepét! Hogyan továbbítódnak a metódushívások paraméterei és a visszatérési értékek a kliens és a szerver között? Egy kliens hogyan talál meg egy adott szolgáltatást egy szerveren? Mely lépéseket kell követni egy RMI alkalmazás megírásakor?

!! szerver, kliens, stub, skeleton (10 pont)

Távoli objektum távoli metódusa hívható, objektumok is közlekedhetnek. Tisztán Java. Kliens és szerveroldali vázak. Interfészek a működés leírására.

• kliens: tudja hogy működik, egy proxy fut a kliensoldalon, ami továbbít a szerver felé.
• szerver: végrehajtja

Három absztakciós réteg:

• stub és szkeleton réteg: a fejlesztő ezen keresztül veheti igénybe a szerver szolgáltatásait, a szerver oldalon ezek kapcsolódnak az implementált szolgáltatáshoz
• távoli referencia réteg: a kliensek távoli objektumokra való hivatkozását kezeli
• transzport réteg: TCP/IP

Stub működése:

1. kapcsolat felépítése a távoli JVM-el
2. marshalling
3. várakozás eredményre
4. unmarshalling
5. eredmények visszaadása a hívónak

!! skeleton-ra nincs már szükség (2 pont)

JDK1.2-től már nem kell a skeleton segédosztály (a stub protokoll továbbfejlesztése miatt). Amúgy a marshalling és a hívás elvégzéséért felelt.

!! marshalling, unmarshalling (6 pont)

marshalling: szerializáció és átküldés unmarshalling: eredmények olvasása (deszerializáció)

!! RMI Registry (5 pont)

Kell a távoli egyedre referencia. Megoldás: naming vagy directory service, =java.rmi.Naming= osztály

Szerver oldalon van =java.rmi.registry.Registry=.

!! lépések (7 pont)

1. Interfész megírása (=java.rmi.Remote= kiterjesztése)
2. Szolgáltatás-implementáció elkészítése
3. Stubok létrehozása

• • =rmic Osztálynév= generálja

1. Szerver létrehozása a kérések fogadására
2. Kliens létrehozása
3. A rendszer beindítása

• • =rmiregistry= parancs
  • =java Server=
  • +kliens

-- palacsint - 2007.01.08. -- palacsint - 2007.01.11.