AbschnitteBearbeiten

Die Struktur der Java-Klassendatei besteht aus 10 grundlegenden Abschnitten:

• Magic Number: 0xCAFEBABE
• Version des Klassendateiformats: die Minor- und Major-Version der Klassendatei
• Constant Pool: Pool von Konstanten für die Klasse
• Zugriffsflags: z.B. ob die Klasse abstrakt, statisch usw. ist
• Diese Klasse: Der Name der aktuellen Klasse
• Superklasse: Der Name der Superklasse
• Interfaces: Alle Schnittstellen in der Klasse
• Felder: Alle Felder in der Klasse
• Methoden: Beliebige Methoden in der Klasse
• Attribute: Alle Attribute der Klasse (z. B. der Name der Quelldatei usw.)

Magic NumberEdit

Klassendateien werden durch den folgenden 4-Byte-Header (in Hexadezimal) gekennzeichnet: CA FE BA BE (die ersten 4 Einträge in der folgenden Tabelle). Die Geschichte dieser magischen Zahl wurde von James Gosling erklärt, der sich auf ein Restaurant in Palo Alto bezog:

„Wir gingen früher zum Mittagessen in ein Lokal namens St. Michael’s Alley. Laut einer lokalen Legende traten dort in der dunklen Vergangenheit die Grateful Dead auf, bevor sie groß rauskamen. Es war ein ziemlich abgefahrener Ort, der definitiv eine Art Grateful Dead Place war. Als Jerry starb, errichteten sie sogar einen kleinen buddhistischen Schrein. Wenn wir dort hingingen, nannten wir den Ort Cafe Dead. Irgendwann ist mir aufgefallen, dass das eine HEX-Zahl ist. Ich war gerade dabei, den Code für ein Dateiformat zu überarbeiten und brauchte ein paar magische Zahlen: eine für die persistente Objektdatei und eine für Klassen. Ich benutzte CAFEDEAD für das Objektdateiformat, und bei der Suche nach 4-Zeichen-Hex-Wörtern, die nach „CAFE“ passten (das schien ein gutes Thema zu sein), stieß ich auf BABE und beschloss, es zu benutzen, was zu diesem Zeitpunkt weder besonders wichtig noch dazu bestimmt schien, irgendwo anders als im Mülleimer der Geschichte zu landen. So wurde CAFEBABE das Klassendateiformat und CAFEDEAD das Format für persistente Objekte. Aber die Möglichkeit, persistente Objekte zu erstellen, wurde abgeschafft, und damit auch die Verwendung von CAFEDEAD – es wurde schließlich durch RMI ersetzt.

Allgemeines LayoutEdit

Da die Klassendatei Elemente mit variabler Größe und keine eingebetteten Datei-Offsets (oder Zeiger) enthält, wird sie in der Regel sequentiell geparst, vom ersten Byte bis zum Ende. Auf der untersten Ebene wird das Dateiformat anhand einiger grundlegender Datentypen beschrieben:

• u1: eine vorzeichenlose 8-Bit-Ganzzahl
• u2: eine vorzeichenlose 16-Bit-Ganzzahl in Big-Endian-Byte-Reihenfolge
• u4: eine vorzeichenlose 32-Bit-Ganzzahl in Big-Endian-Byte-Reihenfolge
• table: ein Array von Elementen variabler Länge eines bestimmten Typs. Die Anzahl der Elemente in der Tabelle wird durch eine vorangestellte Zählnummer identifiziert (die Zählnummer ist ein u2), aber die Größe der Tabelle in Bytes kann nur durch die Untersuchung der einzelnen Elemente bestimmt werden.

Einige dieser Grundtypen werden dann je nach Kontext als Werte höherer Ebene (wie Zeichenketten oder Gleitkommazahlen) neu interpretiert.es gibt keine Erzwingung der Wortausrichtung, und daher werden keine Auffüllungsbytes verwendet.das Gesamtlayout der Klassendatei ist in der folgenden Tabelle dargestellt.

Darstellung in einer C-ähnlichen ProgrammierspracheBearbeiten

Da C keine Arrays mit mehreren variablen Längen innerhalb einer Struktur unterstützt, lässt sich der folgende Code nicht kompilieren und dient nur zur Demonstration.

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;}

Der KonstantenpoolBearbeiten

In der Konstantenpooltabelle werden die meisten literalen konstanten Werte gespeichert. Dazu gehören Werte wie Zahlen aller Art, Zeichenketten, Bezeichnernamen, Verweise auf Klassen und Methoden sowie Typdeskriptoren. Alle Indizes oder Verweise auf bestimmte Konstanten in der Konstanten-Pool-Tabelle werden durch 16-Bit-Zahlen (Typ u2) angegeben, wobei sich der Indexwert 1 auf die erste Konstante in der Tabelle bezieht (der Indexwert 0 ist ungültig).

Aufgrund historischer Entscheidungen, die während der Entwicklung des Dateiformats getroffen wurden, entspricht die Anzahl der Konstanten in der Konstanten-Pool-Tabelle nicht der Anzahl der Konstanten, die der Tabelle vorangestellt ist. Erstens beginnt der Index der Tabelle bei 1 (und nicht bei 0), aber die Anzahl sollte eigentlich als maximaler Index plus 1 interpretiert werden. Außerdem belegen zwei Arten von Konstanten (longs und doubles) zwei aufeinanderfolgende Slots in der Tabelle, obwohl der zweite Slot ein Phantom-Index ist, der nie direkt verwendet wird.

Der Typ jedes Elements (Konstante) im Konstanten-Pool wird durch ein anfängliches Byte-Tag identifiziert. Die Anzahl der Bytes, die diesem Tag folgen, und ihre Interpretation hängen dann von dem Tag-Wert ab. Die gültigen Konstantentypen und ihre Tag-Werte sind:

Es gibt nur zwei integrale konstante Typen, integer und long. Andere ganzzahlige Typen, die in der Hochsprache vorkommen, wie boolean, byte und short, müssen als ganzzahlige Konstante dargestellt werden.

Klassennamen in Java werden, wenn sie vollständig qualifiziert sind, traditionell durch Punkte getrennt, wie z.B. „java.lang.Object“. Innerhalb der Low-Level-Klassenreferenzkonstanten erscheint jedoch eine interne Form, die stattdessen Schrägstriche verwendet, wie z. B. „java/lang/Object“.

Die Unicode-Strings sind trotz des Namens „UTF-8-String“ nicht wirklich nach dem Unicode-Standard kodiert, obwohl er ähnlich ist. Es gibt zwei Unterschiede (siehe UTF-8 für eine vollständige Diskussion). Der erste besteht darin, dass der Codepunkt U+0000 als Zwei-Byte-Sequenz C0 80 (in Hexadezimalzeichen) anstelle der Standard-Ein-Byte-Kodierung 00 kodiert wird. Der zweite Unterschied besteht darin, dass zusätzliche Zeichen (außerhalb des BMP bei U+10000 und darüber) mit einer Surrogat-Paar-Konstruktion ähnlich wie bei UTF-16 kodiert werden, anstatt direkt mit UTF-8 kodiert zu werden. In diesem Fall wird jedes der beiden Surrogate separat in UTF-8 kodiert. Zum Beispiel wird U+1D11E als 6-Byte-Sequenz ED A0 B4 ED B4 9E kodiert, anstatt der korrekten 4-Byte-UTF-8-Kodierung von F0 9D 84 9E.