SzakaszokSzerkesztés

A Java osztályfájl szerkezetének 10 alapvető szakasza van:

• Mágikus szám: 0xCAFEBABE
• Az osztályfájl formátumának verziója: az osztályfájl kisebb és nagyobb verziója
• Állandó állomány: Az osztály konstansainak tárháza
• Access Flags: például, hogy az osztály absztrakt, statikus stb.
• This Class: Az aktuális osztály neve
• Super Class: A szuperosztály neve
• Interfaces: Az osztályban lévő bármely interfész
• Fields: Az osztályban található bármely mező
• Módszerek: Bármely metódus az osztályban
• Attribútumok: Az osztály bármely attribútuma (például a forrásfájl neve stb.)

Magic NumberEdit

Az osztályfájlokat a következő 4 bájtos fejléccel azonosítjuk (hexadecimálisan): CA FE BA BE (az alábbi táblázat első 4 bejegyzése). Ennek a bűvös számnak a történetét James Gosling egy Palo Alto-i étteremre utalva magyarázta el:

“Egy St Michael’s Alley nevű helyre jártunk ebédelni. A helyi legenda szerint a mély, sötét múltban a Grateful Dead lépett fel ott, mielőtt nagyot alkottak. Eléggé funky hely volt, ami határozottan egy Grateful Dead-féle hely volt. Amikor Jerry meghalt, még egy kis buddhista szentélyt is felállítottak. Amikor oda jártunk, Cafe Deadként emlegettük a helyet. Valamikor aztán észrevettük, hogy ez egy HEX szám. Átalakítottam néhány fájlformátum kódot, és szükségem volt néhány mágikus számra: egy a perzisztens objektumfájlhoz, és egy az osztályokhoz. A CAFEDEAD-et használtam az objektumfájl formátumhoz, és a “CAFE” után megfelelő 4 karakteres hexa szavak keresése közben (jó témának tűnt) rábukkantam a BABE-ra, és úgy döntöttem, hogy ezt fogom használni. akkoriban nem tűnt túl fontosnak, vagy arra szántam, hogy a történelem szemétkosarába kerüljön. Így lett a CAFEBABE az osztályfájl-formátum, a CAFEDEAD pedig a tartós objektumformátum. De a perzisztens objektum lehetőség eltűnt, és vele együtt eltűnt a CAFEDEAD használata is – végül az RMI váltotta fel.

Általános layoutEdit

Mivel az osztályfájl változó méretű elemeket tartalmaz, és nem tartalmaz beágyazott fájloffszetet (vagy mutatót) is, általában szekvenciálisan, az első bájttól a vége felé elemzik. A legalacsonyabb szinten a fájlformátum néhány alapvető adattípussal írható le:

• u1: egy előjel nélküli 8 bites egész szám
• u2: egy előjel nélküli 16 bites egész szám big-endian bájtsorrendben
• u4: egy előjel nélküli 32 bites egész szám big-endian bájtsorrendben
• táblázat: valamilyen típusú, változó hosszúságú elemek tömbje. A táblázatban lévő elemek számát az azt megelőző számlálószám azonosítja (a számlálószám egy u2), de a táblázat bájtokban kifejezett mérete csak az egyes elemek vizsgálatával határozható meg.

Ezek közül az alapvető típusok közül néhányat a kontextustól függően magasabb szintű értékként (például stringként vagy lebegőpontos számként) értelmezünk újra.Nincs szókiigazítás kényszerítése, ezért soha nem használunk töltőbájtokat.Az osztályfájl teljes elrendezése a következő táblázatban látható.

C-szerű programozási nyelven való ábrázolásSzerkesztés

Mivel a C nem támogatja a többszörös változó hosszúságú tömböket egy struktúrán belül, az alábbi kód nem fordítható le, és csak demonstrációként szolgál.

struct Class_File_Format { u4 magic_number; u2 minor_version; u2 major_version; u2 constant_pool_count; cp_info constant_pool; u2 access_flags; u2 this_class; u2 super_class; u2 interfaces_count; u2 interfaces; u2 fields_count; field_info fields; u2 methods_count; method_info methods; u2 attributes_count; attribute_info attributes;}

A konstanskészletEdit

A konstanskészlet táblában tároljuk a legtöbb literális konstans értéket. Ide tartoznak az olyan értékek, mint a mindenféle számok, karakterláncok, azonosítónevek, osztályokra és metódusokra való hivatkozások, valamint típusleírók. A konstanskészlet-táblában az összes indexet, illetve a konkrét konstansokra való hivatkozást 16 bites (u2 típusú) számok adják meg, ahol az 1-es indexérték a táblázat első konstansára utal (a 0-s indexérték érvénytelen).

A fájlformátum fejlesztése során hozott történelmi döntések miatt a konstanskészlet-táblában lévő konstansok száma valójában nem azonos a táblázatot megelőző konstanskészlet számával. Először is, a táblázat indexelése 1-től kezdődik (és nem 0-tól), de a számot valójában a maximális index plusz egy indexként kell értelmezni. Továbbá, a konstansok két típusa (hosszúak és duplák) két egymást követő helyet foglal el a táblázatban, bár a második ilyen hely egy fantomindex, amelyet soha nem használunk közvetlenül.

A konstanskészletben lévő minden egyes elem (konstans) típusát egy kezdeti bájtcímke azonosítja. Az ezt követő bájtok száma és értelmezése a tag értékétől függ. Az érvényes konstans típusok és azok tag értékei a következők:

Kizárólag két integrál konstans típus létezik, az integer és a long. A magas szintű nyelvben megjelenő egyéb integrál típusokat, mint például a boolean, a byte és a short, egész konstansként kell ábrázolni.

A Java-ban az osztálynevek, ha teljes minősítésűek, hagyományosan ponttal vannak elválasztva, például “java.lang.Object”. Az alacsony szintű osztályhivatkozási konstansokon belül azonban megjelenik egy olyan belső forma, amely ehelyett kötőjeleket használ, például “java/lang/Object”.

A Unicode karakterláncok az “UTF-8 string” elnevezés ellenére valójában nem a Unicode szabvány szerint vannak kódolva, bár hasonló. Két különbség van (lásd az UTF-8 teljes körű tárgyalását). Az első az, hogy az U+0000 kódpontot a szabványos egybájtos 00 kódolás helyett a kétbájtos C0 80 (hexában) kódolással kódolják. A második különbség az, hogy a kiegészítő karakterek (a BMP-n kívül eső karakterek az U+10000 és afelett) kódolása az UTF-16-hoz hasonló helyettesítőpáros konstrukcióval történik, ahelyett, hogy közvetlenül az UTF-8 kódolással történne. Ebben az esetben mindkét helyettesítő karaktert külön-külön kódoljuk az UTF-8-ban. Például az U+1D11E kódolása a 6 bájtos ED A0 B4 ED B4 9E szekvenciaként történik, ahelyett, hogy a helyes 4 bájtos UTF-8 kódolás F0 9D 84 9E.

lenne.