DE69813618T2

DE69813618T2 - Kombinieren von mehreren klassendateien in einer laufzeitabbildung

Info

Publication number: DE69813618T2
Application number: DE69813618T
Authority: DE
Inventors: E. Markley; M. Sauntry
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1997-12-16
Filing date: 1998-12-16
Publication date: 2003-10-23
Anticipated expiration: 2018-12-17
Also published as: EP1040409B1; CA2306118C; US6349344B1; JP2002508560A; ATE237836T1; DE69813618D1; EP1040409A1; JP4372348B2; CA2306118A1; WO1999031576A1

Description

GEBIET DER ERFINDUNG

Die Erfindung betrifft allgemein Java-Klassendateien, und spezieller betrifft sie die Kombination derartiger Dateien zu einem Laufzeitbild.

HINTERGRUND DER ERFINDUNG

Java ist eine relativ neue objektorientierte Programmiersprache, die Gegenstand des Interesses vieler Programmierer wurde. Idealerweise ist Java dahingehend eine architekturneutrale und portierbare Sprache, dass dieselbe Version vorgegebenerweise ohne jede Modifizierung auf jeder Plattform laufen sollte - d. h., dass ein Computer, auf dem eine Version des Betriebssystems Microsoft Windows läuft, ein Computer, auf dem eine Version des Betriebssystems Apple MacOS läuft, ein Computer, auf dem eine Version des Betriebssystems UNIX läuft, usw. alle dazu in der Lage sein sollten, mit derselben Version eines Java-Programms zu arbeiten. Das heißt, dass vorgegebenerweise keine "implementierungsabhängigen" Gesichtspunkte der Java-Sprachspezifikation bestehen.
Tatsächlich können in der Realität in Java geschriebene Programme realistischerweise nicht auf jeder beliebigen Plattform ohne Modifizierung laufen, um Unterschiede zwischen verschiedenen Plattformen zuzulassen, was auf charakteristischen Einschränkungen und Besonderheiten jeder vorgegebenen Plattform beruht. Zum Beispiel ist Microsoft Windows CE ein kompaktes, effizientes und skalierbares Betriebssystem, das bei einer großen Anzahl eingebetteter Produkte verwendet werden kann, von Hand-PCs bis zu spezialisierten Industriesteuerungen und Geräten der Verbraucherelektronik. Viele Geräte, die Microsoft Windows CE nutzen, sind dazu vorgesehen, über einen relativ geringen Umfang an Direktzugriffsspeicher (RAM) zu verfügen, wie einem Megabyte, um zu gewährleisten, dass die Geräte billig, kompakt und energienutzungseffizient bleiben.
Ferner verfügen zur Nutzung von Microsoft Windows CE konzipierte Geräte typischerweise über weniger leistungsfähige Prozessoren als das, was sich typischerweise in Computern findet, die dazu vorgesehen sind, mit leistungsfähigeren Betriebssystemen wie Microsoft Windows NT zu laufen.
Die Art von Java steht jedoch nicht notwendigerweise mit dem Lauf von in Java geschriebenen Programmen in derartigen Umgebungen wie Microsoft Windows CE in Einklang. Java ist sowohl eine kombinierte als auch eine interpretierte Sprache. Java-Quellencode wird in einfache Binäranweisungen - die als Java-Bytecodes oder J-Codes bezeichnet werden - umgewandelt, stark ähnlich wie normaler Mikroprozessor-Maschinencode. Während jedoch Quellencode in C oder C++ an charakteristische Anweisungen für einen speziellen Prozessor angepasst ist, wird Java-Quellencode zu Befehlen in einem universellen Format kompiliert, das als virtuelle Java-Maschine bekannt ist.
Die virtuelle Java-Maschine ist demgemäß ein natives Programm, das innerhalb eines Betriebssystems läuft, um Java- Bytecode zu interpretieren und auszuführen. Die Grundeinheit von Java-Code ist die Klasse. Wie bei anderen objektorientierten Sprachen sind Klassen Anwendungskomponenten, die ausführbaren Code und Daten enthalten sollen. Kompilierte Java-Klassen werden in einem universellen Binärformat verteilt, das Java-Bytecode und andere Klasseninformation ent hält. Klassen können diskret aufrechterhalten werden und in Dateien oder Archiven in einem lokalen System oder einem Netzwerkserver gespeichert werden. Typischerweise werden Klassen zur Laufzeit dynamisch geladen und geparst (syntaktisch analysiert), wenn sie von einer Anwendung benötigt werden.
Anders gesagt, wurde Java so konzipiert, dass Softwareimplementierungen des Laufzeitsystems ihr Funktionsvermögen dadurch optimieren können, dass Bytecode im Vorbeigehen in nativen Maschinencode kompiliert wird. Es wird eine Klassendatei geladen und geparst, so dass sie zur Laufzeit auf "just in time"-Basis kompiliert wird. Demgemäß, existieren, wenn ein Java-Programm durch eine virtuelle Java-Maschine abgearbeitet wird, schließlich zwei Versionen benötigter Klassendateien: die Bytecodeversionen, die anfangs vor dem Lauf des Programms existieren, und die geladenen und geparsten Versionen, wenn das Programm das erste Mal auf der virtuellen Java-Maschine läuft.
Bei diesem Konzept der Java-Programmiersprache bestehen im Zusammenhang mit Plattformen wie der Plattform Microsoft Windows CE, die auf Effizienz und Kosten konzipiert sind und demgemäß nicht über so viel Speicher und langsamere Prozessoren als z. B. Desktopcomputer, auf denen Microsoft Windows NT läuft, verfügen, konzipiert sind. Zunächst verwendet ein typisches Java-Programm viele Klassendateien, so dass das Laden und Parsen dieser Klassendateien zur Laufzeit auf einem weniger leistungsfähigen Prozessor viel Zeit benötigt. Zum Beispiel wurde herausgefunden, dass das Betreiben eines einfachen "Hallo Welt"-Programms - z. B. eines Programms, das dafür sorgt, dass auf dem Schirm die Worte "Hallo Welt" angezeigt werden - für die Ausführung auf einem Handgerät mit einem Prozessor, der mit ungefähr 40 Megahertz läuft, wegen des anfänglichen Ladens und Parsens der Klassendateien zur Laufzeit mehr als neun Minuten benötigen kann.
Ein Gesichtspunkt dieses anfänglichen Ladens und Parsens ist häufig die Übersetzung der Bytecodes der Java-Klassendateien vom Big-Endian-Format in das Little-Endian-Format. Das heißt, dass Bytecodes in Java-Klassendateien im Big-Endian- Format vorliegen, so dass die Bytes vom geringstsignifikanten zum höchstsignifikanten (z. B. 0, 1, 2, 3) geordnet sind, wohingegen auf vielen Plattformen das Little-Endian- Format verwendet wird, bei dem Bytes vom höchstsignifikanten zum geringstsignifikanten (z. B. 3, 2, 1, 0) geordnet sind. Ein anderer Gesichtspunkt dieses anfänglichen Ladens und Parsens besteht darin, dass das Java-Klassendateiformat den Ort einer nativen Mitgliedsfunktion nicht spezifiziert, so dass die virtuelle Maschine bei einem Prozess zum Auffinden des gewünschten Verfahrens alle geladenen Dateien durchsuchen muss.
Ein zweiter deutlicher Nachteil steht mit der Tatsache in Zusammenhang, dass jede Java-Klassendatei eine Kopie aller Daten enthält, die in dieser Klasse laufen müssen - z. B. Information betreffend die Superklassen, mit denen die Klasse in Beziehung steht. Diese Daten werden häufig auch in andere Klassendateien vervielfältigt, was in unnötiger Weise Raum vergeudet. Dies ist besonders bei Geräten mit begrenzter RAM-Menge problematisch. Zum Beispiel wurde herausgefunden, dass bei Java 1.1 (genauer gesagt, beim Java Development Kit 1.1 oder bei JDK 1.1) ein einfaches "Hallo Welt"- Programm in einem bestimmten Handgerät zur Laufzeit einen Speicherabbildungsumfang von über 700 Kilobyte oder nahezu 70% des verfügbaren einen Megabyte an RAM auf weist. Ein derartiges Handgerät kann auch ungefähr 300 Kilobytes an RAM benötigen, um den Schirm aufrechtzuerhalten, was bedeutet, dass Programme mit größerer Kompliziertheit als ein einfaches "Hallo Welt"-Programm wahrscheinlich überhaupt nicht auf dem Gerät laufen.
Drittens besteht ein einschlägiges Problem darin, dass bei einem typischen Java-Laufzeitsystem die Java-Klassendateien in einem Speicher abgelegt sind. Dies kann ein RAM oder ein Festwertspeicher (ROM) sein. Wenn die virtuelle Java-Maschine diese Dateien zur Ausführung benötigt, werden sie in den RAM geladen und geparst, so dass die sich ergebenden Daten während der Ausführungs im RAM abgespeichert werden. Dies bedeutet, dass während des Laufs eines Java-Programms tatsächlich zwei Versionen der in der Maschine gespeicherten benötigten Klassendateien existieren - die ungeladenen und ungeparsten Java-Klassendateien im Speicher (entweder im RAM oder im ROM) und die geladenen und geparsten Java-Klassendateien im RAM. Für Geräte mit eingeschränktem Speicher stellt diese eine Belastung dar.
Im EPA-Patent EP-A-0810522 von sun Microsystems, Inc. ist das Konvertieren dynamisch ladbarer Java-Klassen in statisch ladbare Klassen angegeben, die als ausführbares Modul gespeichert werden. EP-A-0810522 erörtert auch eine Ladeeinrichtung für statische Klassen, die die Klassenstruktur so modifiziert, dass sie statisch geladen werden kann. Diese statischen Klassen werden zur Bootzeit in den Direktzugriffsspeicher geladen und dann zur Laufzeit auf herkömmliche Weise verarbeitet.
Daher besteht Bedarf an einer Lösung, die diese Nachteile und Mängel beim Laden und Parsen von Java-Klassendateien zur Laufzeit durch eine virtuelle Java-Maschine überwindet, so dass Java-Programme in realistischer Weise eher auf langsameren Plattformen mit eingeschränktem Speicher laufen können, wie Handgeräten, die mit Microsoft Windows CE arbeiten.

ZUSAMMENFASSUNG DER ERFINDUNG

Die oben genannten Mängel, Nachteile und Probleme sind durch die Erfindung berücksichtigt, wie sie in den beigefügten Ansprüchen dargelegt ist. Die Erfindung beschreibt das Kombinieren mehrerer Java-Klassendateien in einem Laufzeitbild. Das Laufzeitbild der Java-Klassendateien ist dergestalt, dass sich die Klassendateien für eine virtuelle Java-Maschine in einem vorab geladenen und vorab geparsten Zustand befinden. Wünschenswerterweise ist das Laufzeitbild eine im Festwertspeicher (ROM) abgespeicherte DLL-Datei, und sie enthält nicht-redundante Daten.
Das Laufzeitbild wird wünschenswerterweise durch eine gesonderte Hilfseinrichtung erzeugt, die vorab eine vorgegebene Sammlung an Java-Klassendateien lädt und vorab parst, so dass die virtuelle Java-Maschine die Dateien zur Laufzeit nicht laden und parsen muss, sondern sie sich statt dessen auf das Laufzeitbild selbst stützen kann. Wünschenswerterweise gehört dazu das Übersetzen der Bytecodes der Java- Klassendateien vom Big-Endian-Format in das Little-Endian- Format sowie das Erzeugen importierbarer Datensätze, so dass Funktionsdatenstrukturen nativer Elemente darauf zeigen, was eine schnellere Funktionsauflösung nativer Elemente erlaubt.
Daher sorgt die Erfindung für Vorteile, die sich im Stand der Technik nicht finden. Erstens bedeutet, da die Java- Klassendateien im Laufzeitbild vorab geladen und vorab geparst sind, die Tatsache, dass die virtuelle Java-Maschine dieselben zur Laufzeit nicht laden und parsen muss, dass das Ausführen von Java-Programmen viel schneller ausgeführt wird. Zum Beispiel wurde herausgefunden, dass der Ablauf eines einfachen "Hallo Welt"-Programms für die Ausführung auf einem Handgerät mit einem Prozessor, der mit ungefähr 40 Megahertz läuft, weniger als eine Sekunde benötigt, im Ver gleich zu mehr als neun Minuten auf demselben Gerät, wenn die virtuelle Maschine zuerst die erforderlichen Klassendateien laden und parsen muss.
Zweitens wird, da in wünschenswerter Weise redundante Daten beseitigt werden, wenn die geladenen und geparsten Klassendateien zu einer einzelnen DLL-Datei kombiniert werden, an knappem Raum im Speicher gespart. Zum Beispiel wurde herausgefunden, dass bei Java 1.1.3 (genauer gesagt, Java Development Kit 1.1.3 oder JDK 1.1.3) in einigen Fällen eine Größenverringerung der Laufzeit-Bilddatei von 30% im Vergleich zum bekannten Laden und Parsen von Klassendateien zur Laufzeit erzielt werden kann.
Drittens ist das Laufzeitbild die einzige Version von Java- Klassendateien, die innerhalb eines vorgegebenen Geräts benötigt wird. Ferner wird diese einzige Version wünschenswerterweise im ROM abgespeichert und nicht im Direktzugriffsspeicher (RAM). Demgemäß ist, wenn im Stand der Technik zwei Versionen der Klassendateien existieren, die erste ein ungeladener und ungeparster Zustand, und die zweite ist ein zur Laufzeit geladener und geparster Zustand, wobei häufig diese zwei Versionen der Klassendateien beide im RAM vorhanden sind, während im Vergleich hierzu bei der Erfindung nur eine Version der Klassendateien vorliegt (nur die geladene und geparste Version), die wünschenswerterweise im ROM vorhanden ist. Dies spart an knappem Raum.
Durch die Erfindung werden Geräte, Computer, computerlesbare Medien und Systeme variablen Umfangs beschrieben. Zusätzlich zu den hier beschriebenen Gesichtspunkten und Vorteilen der Erfindung werden weitere Gesichtspunkte und Vorteile derselben unter Bezugnahme auf die Zeichnungen und durch Lesen der folgenden detaillierten Beschreibung ersichtlich.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 ist ein Diagramm der Hardware und der Betriebsumgebung, in deren Zusammenhang Ausführungsformen der Erfindung realisiert werden können;
Fig. 2(a) und 2(b) sind Diagramme zum Veranschaulichen eines Systems gemäß einer Ausführungsform der Erfindung im Vergleich zu einem bekannten System; und
Fig. 3(a) und 3(b) sind Flussdiagramme von Verfahren gemäß einer Ausführungsform der Erfindung.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG

Der folgenden detaillierten Beschreibung beispielhafter Ausführungsformen der Erfindung ist auf die beigefügten Zeichnungen Bezug genommen, die einen Teil derselben bilden und in der zur Veranschaulichung spezielle beispielhafte Ausführungsformen dargestellt sind, gemäß denen die Erfindung realisiert werden kann. Diese Ausführungsformen sind in ausreichendem Detail beschrieben, um den Fachmann in die Lage zu versetzen, die Erfindung auszuführen. Daher ist die folgende detaillierte Beschreibung nicht in beschränkendem Sinn zu verstehen, und der Schutzumfang der Erfindung ist alleine durch die beigefügten Ansprüche definiert.
Die detaillierte Beschreibung ist in vier Abschnitte unterteilt. Im ersten Abschnitt werden die Hardware und die Betriebsumgebung beschrieben, in deren Zusammenhang Ausführungsformen der Erfindung realisiert werden können. Im zweiten Abschnitt wird eine Beschreibung einer Ausführungsform der Erfindung auf Systemebene im Vergleich zu einem bekannten System angegeben. Im dritten Abschnitt werden Verfahren für eine Ausführungsform der Erfindung angegeben. Im vierten Abschnitt wird eine Schlussfolgerung der detaillierten Beschreibung gegeben.

Hardware und Betriebsumgebung

In der Fig. 1 ist ein Diagramm der Hardware und der Betriebsumgebung, in deren Zusammenhang Ausführungsformen der Erfindung realisiert werden können, dargestellt. Die Beschreibung der Fig. 1 soll für eine kurze, allgemeine Beschreibung geeigneter Computerhardware und einer geeigneten Rechenumgebung, in deren Zusammenhang die Erfindung realisiert werden kann, geben. Obwohl es nicht erforderlich ist, wird die Erfindung im allgemeinen Zusammenhang computerausführbarer Anweisungen, wie Programmmodulen, beschrieben, die durch einen Computer wie einen PC ausgeführt werden. Im Allgemeinen enthalten Programmmodule Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., die spezielle Aufgaben ausführen oder spezielle abstrakte Datentypen realisieren.
Darüber hinaus ist es dem Fachmann erkennbar, dass die Erfindung mit anderen Computersystemkonfigurationen realisiert werden kann, einschließlich Handgeräten, wie solchen, auf denen Microsoft Windows CE läuft, Mehrprozessorsystemen, auf Mikroprozessoren beruhender oder programmierbarer Verbraucherelektronik, Netzwerk-PCs, Minicomputern, Großcomputern, PCs, auf denen Microsoft Windows NT läuft, und dergleichen. Die Erfindung kann auch in verteilten Rechenumgebungen ausgeübt werden, in denen Aufgaben durch entfernte Verarbeitungsvorrichtungen ausgeführt werden, die über ein Kommunikationsnetzwerk verbunden sind. In einer verteilten Rechenumgebung können sich Programmmodule sowohl in lokalen als auch in entfernten Speichervorrichtungen befinden.
Die Hardware und die Betriebsumgebung der Fig. 1 zum Reali sieren der Erfindung verfügt über eine universelle Rechenvorrichtung in Form eines Computers 20 mit einer Verarbeitungseinheit 21, einem Systemspeicher 22 und einem Systembus 23, der funktionsmäßig verschiedene Systemkomponenten einschließlich des Systemspeichers mit der Verarbeitungseinheit 21 verbindet. Es kann nur eine Verarbeitungseinheit 21 vorhanden sein, oder mehrere, so dass der Prozessor des Computers 20 über eine einzelne Verarbeitungseinheit (CPU) oder mehrere verfügt, was allgemein als parallele Verarbeitungsumgebung bezeichnet wird. Der Computer 20 kann ein herkömmlicher Computer, ein verteilter Computer oder ein beliebiger anderer Computertyp sein; die Erfindung ist nicht in dieser Weise beschränkt.
Der Systembus 23 kann einer von mehreren Typen von Busstrukturen sein, einschließlich einem Speicherbus oder Speichercontroller, einem Peripheriebus und einem lokalen Bus unter Verwendung einer Anzahl von Busarchitekturen. Der Systemspeicher kann auch einfach als Speicher bezeichnet werden, und er verfügt über einen Festwertspeicher (ROM) 24 und einen Direktzugriffsspeicher (RAM) 25. Ein grundlegendes Eingangs/Ausgangs-System (BIOS) 26, das die Grundroutinen enthält, die dazu beitragen, Information zwischen Elementen innerhalb des Computers 20 zu übertragen, wie während des Hochfahrens, ist im ROM 24 gespeichert. Der Computer 20 verfügt ferner über ein Festplattenlaufwerk 27 zum Lesen von einer nicht dargestellten Festplatte und zum Schreiben auf diese, ein Magnet-Plattenlaufwerk 28 zum Lesen von einer herausnehmbaren magnetischen Platte 29 und zum Schreiben auf diese, und ein optisches Plattenlaufwerk 30 zum Lesen von einer herausnehmbaren optischen Platte 31 wie einer CD-ROM oder einem anderen optischen Träger, oder zum Schreiben darauf.
Das Festplattenlaufwerk 27, das Magnet-Plattenlaufwerk 28 und das optische Plattenlaufwerk 30 sind über eine Festplattenlaufwerk-Schnittstelle 32, eine Magnetplattenlaufwerk- Schnittstelle 33 bzw. eine Schnittstelle 34 für das optische Plattenlaufwerk mit dem Systembus 23 verbunden. Die Laufwerke und ihre zugehörigen computerlesbaren Träger sorgen für nichtflüchtige Speicherung computerlesbarer Anweisungen, Datenstrukturen, Programmmodule und anderer Daten für dem Computer 20. Vom Fachmann ist zu beachten, dass jeglicher Typ computer lesbar er Träger, die Daten speichern können, auf die ein Computer zugreifen kann, wie Magnetkassetten, Flashspeicherkarten, digitale Videoplatten, Bernoulli-Kassetten, Direktzugriffsspeicher (RAMs), Festwertspeicher (ROMs) und dergleichen in der beispielhaften Betriebsumgebung verwendet werden können.
Auf der Festplatte, der Magnetplatte 29, der optischen Platte 31, dem ROM 24 oder dem RAM 25 kann eine Anzahl von Programmmodulen gespeichert sein einschließlich eines Betriebssystems 35, eines oder mehrerer Anwendungsprogramme 36, andere Programmmodule 37 sowie Programmdaten 38. Ein Benutzer kann über Eingabevorrichtungen wie eine Tastatur 40 und eine Zeigevorrichtung 42 Befehle und Information in den PC 20 eingeben. Zu anderen Eingabevorrichtungen (nicht dargestellt) können ein Mikrofon, ein Joystick, ein Gamepad, eine Satellitenschüssel, ein Scanner oder dergleichen gehören. Diese und andere Eingabevorrichtungen werden häufig über eine Schnittstelle 46 eines seriellen Ports, der mit dem Systembus verbunden ist, mit der Verarbeitungseinheit 21 verbunden, jedoch können sie über andere Schnittstellen angeschlossen werden, wie einen Parallelport, einen Gameport oder einen universellen seriellen Bus (usw.). Mit dem Systembus 23 ist auch ein Monitor 47 oder ein anderer Typ einer Anzeigevorrichtung über eine Schnittstelle, wie einen Videoadapter 48, verbunden. Zusätzlich zum Monitor verfügen Computer typischerweise über andere Ausgabe-Peripherievorrich tungen (nicht dargestellt), wie Lautsprecher und Drucker.
Der Computer 20 kann in einer Netzwerkumgebung unter Verwendung logischer Verbindungen zu einem oder mehreren entfernten Computer, wie einem entfernten Computer 49, arbeiten. Diese logischen Verbindungen werden durch eine Kommunikationsvorrichtung erzielt, die mit dem Computer 20 oder einem Teil desselben verbunden ist; die Erfindung ist auf keinen speziellen Typ einer Kommunikationsvorrichtung beschränkt. Der entfernte Computer 49 kann ein anderer Computer, ein Server, ein Router, ein Netzwerk-PC, ein Client, eine Peervorrichtung oder ein anderer üblicher Netzwerkknoten sein, und typischerweise enthält er viele oder alle der Elemente, die oben in Zusammenhang mit dem Computer 20 beschrieben wurden, wobei jedoch in der Fig. 1 nur eine Speichervorrichtung 50 dargestellt ist. Zu den in der Fig. 1 dargestellten logischen Verbindungen gehören ein Nahbereichsnetz (LAN) 51 und ein Fernbereichsnetz (WAN) 52. Derartige Netzwerkumgebungen sind in Büronetzwerken, unternehmensweiten Computernetzwerken, Intranets und dem Internet, die alle Netzwerken sind, üblich.
Wenn der Computer 20 in einer LAN-Netzwerksumgebung verwendet wird, ist er über eine Netzschnittstelle oder einen Netzadapter 53, wobei es sich um einen Typ einer Kommunikationsvorrichtung handelt, mit dem lokalen Netzwerk 51 verbunden. Wenn der Computer 20 in einer WAN-Netzwerksumgebung verwendet wird, verfügt er typischerweise über ein Modem 54, einen Typ einer Kommunikationsvorrichtung, oder irgendeinen anderen Typ einer Kommunikationsvorrichtung zum Ausführen von Kommunikationsvorgänge über das Weitbereichsnetz 52, wie das Internet. Das Modem 54, das intern oder extern sein kann, ist über die Schnittstelle 46 des seriellen Ports mit dem Systembus 23 verbunden. In einer Netzwerkumgebung können Programmmodule, die in Bezug zum PC 20 oder Teilen desselben dargestellt sind, in der entfernten Speichervorrichtung gespeichert sein. Es ist zu beachten, dass die dargestellten Netzwerkverbindungen beispielhaft sind und dass andere Maßnahmen und Kommunikationsvorrichtungen zum Erstellen von Kommunikationsstrecken zwischen den Computern verwendet werden können.
Es wurden die Hardware und die Betriebsumgebungen beschrieben, in deren Zusammenhang Ausführungsformen der Erfindung realisierbar sind. Der Computer, in dessen Zusammenhang Ausführungsformen der Erfindung realisiert werden können, kann ein herkömmlicher Computer, ein verteilter Computer oder irgendein anderer Computertyp sein; die Erfindung ist nicht in dieser Weise beschränkt. Ein derartiger Computer enthält typischerweise eine oder mehrere Verarbeitungseinheiten als Prozessor sowie einen computerlesbaren Träger als Speicher. Der Computer kann auch über eine Kommunikationsvorrichtung wie einen Netzwerkadapter oder ein Modem verfügen, so dass er kommunizierend mit anderen Computern verbunden werden kann.

Beschreibung auf Systemebene

Unter Bezugnahme auf die Fig. 2(a)-2(b) erfolgt eine Beschreibung des Betriebs einer Ausführungsform der Erfindung aus Systemebene im Vergleich zum Betrieb eines bekannten Systems. Ein Diagramm eines Systems, bei dem eine virtuelle Java-Maschine Java-Klassendateien gemäß dem Stand der Technik in einen Direktzugriffsspeicher (RAM) lädt und parst, wie in der Technik bekannt, ist in der Fig. 2(a) dargestellt, während in der Fig. 2(b) ein Diagramm eines Systems dargestellt ist, bei dem Java-Klassendateien vorab in ein Laufzeitbild in einem Festwertspeicher (ROM) geparst und geladen werden, damit sich eine virtuelle Java-Maschine darauf stützen kann, wenn ein Java-Programm abgearbeitet wird, was gemäß eine Ausführungsform der Erfindung erfolgt.
Es wird als Erstes auf die Fig. 2(a) Bezug genommen, gemäß der, gemäß dem Stand der Technik, die virtuelle Java-Maschine 200 zur Laufzeit die Java-Klassendateien 202 in den RAM 204 lädt und parst. Die Java-Klassendateien 202 sind solche Klassendateien, zu denen solche gehören, die zur Ausführung eines vorgegebenen Java-Programms benötigt werden. Im Allgemeinen wurde, mit der Herausgabe von Java 1.1 und folgenden Versionen (d. h. Java Development Kit 1.1 oder JDK 1.1) bestimmt, dass mehr als mindestens ungefähr 160 bis 190 derartiger Java-Klassendateien zur Ausführung selbst einfacher Programme wie eines "Hallo Welt"-Programms benötigt werden. Die Java-Klassendateien 202 werden in einem Speicher wie einem RAM (verschieden vom RAM 204, in den die geparsten und geladenen Java-Klassendateien eingespeichert werden), einen Festwertspeicher (ROM) oder einen Speicher wie ein Festplattenlaufwerk eingespeichert.
Die Struktur von Java-Klassendateien wurde im Abschnitt zum Hintergrund allgemein beschrieben; die Konstruktion und das Format derartigen Klassendateien sind in der Technik bekannt. Insbesondere wird jede Java-Klassendatei typischerweise durch eine Klassensuffixspezifikation gekennzeichnet und durch Bytecode kompiliert. Jede Java-Klassendatei wird gesondert übertragen; alle bei einem Java-Applet oder einer Java-Applikation verwendeten Klassen befinden sich in ihrer eigenen gesonderten Klassendatei. Die Klassendatei ist eine Abfolge von acht Bytes. Werte von 16 und 32 Bits werden durch Lesen von zwei oder vier dieser Bytes und durch Verbinden derselben erzeugt. Jede Klassendatei enthält eine magische Konstante, Information zur Haupt- und Nebenversion, einen Konstantenpool, Information zur Klasse, Information zu jedem der Felder und Verfahren in der Klasse sowie Debugging-Information. Der Konstantenpool besteht darin, wie verschiedene konstante Information zur Klasse gespeichert wird, und es kann ein Unicodestring, ein Klassen- oder Interfacename, eine Bezugsnahme auf ein Feld oder ein Verfahren, ein Zahlenwert oder ein konstanter Stringwert sein.
Die virtuelle Java-Maschine 200 ist ein natives Programm, das innerhalb eines Betriebssystems, wie Microsoft Windows CE, läuft, um ein Java-Programm zu interpretieren und auszuführen, das zuvor in Java-Bytecode kompiliert wurde. Eine virtuelle Java-Maschine wird auch als Java-Laufzeitinterpretierer bezeichnet. Bei der Laufzeitausführung eines Java- Programms lädt die virtuelle Java-Maschine 200 die Java- Klassendateien 202 und parst sie, und sie speichert die Java-Klassendateien im geladenen und geparsten Zustand in den RAM 204 ein. Wie es im Hintergrundabschnitt beschrieben wurde, existieren beim Stand der Technik auf diese Weise zwei Versionen der Java-Klassendateien, nämlich die ursprünglichen Java-Klassendateien, wie durch Java-Klassendateien 202 repräsentiert, und die im RAM 204 gespeicherte geparste und geladene Version. Das Laden und Parsen von Java-Klassendateien ist in der Technik bekannt. Information hinsichtlich Java ist in der Literaturstelle "JAva in a Nutshell: A Desktop Quick Reference", 2. Auflage, 1997 (ISBN 1-56592-262-X) von David Flanagan beschrieben.
Es wird als Nächstes auf die Fig. 2(b) Bezug genommen, gemäß der, entsprechend einer Ausführungsform der Erfindung, der Konverter 250 die Java-Klassendateien 252 in eine Datei 254 lädt und parst, die dann wünschenswerterweise durch eine ROM-Bildeinbrenneinrichtung 258 als Laufzeitbild (wünschenswerterweise als DLL-Datei) in den ROM 256 eingebrannt wird. Demgemäß muss die virtuelle Java-Maschine 206 keine der Java-Klassendateien 252 laden oder parsen, sondern sie kann vielmehr unmittelbar die als Laufzeitbild im ROM 256 abgespeicherte geparste und geladene Version der Klassendateien nutzen. Dies bedeutet, dass an RAM 262 eingespart wird, und es bedeutet auch, dass Java-Programme schneller ausgeführt werden, da zur Laufzeit weniger Overhead ausgeführt werden muss.
Der Konverter 250 und die ROM-Einbrenneinrichtung 258 sind im Allgemeinen Teil eines Computers, eines Computersystems oder eines vom Computer, vom Computersystem getrennten Geräts oder eines Geräts, auf dem die virtuelle Java-Maschine 260 läuft. Zum Beispiel können der Konverter 250 und die ROM-EInbrenneinrichtung 258 auf einer unter Microsoft Windows NT arbeitenden Workstation laufen, so dass der Konverter 250 die Java-Klassendateien 252 als Eingangsgröße verwendet (wie in einem Speicher wie einem Festplattenlaufwerk der Workstation abgespeichert), und er die sich ergebende Datei 254 ausgibt, die dann von der ROM-Bildeinbrenneinrichtung 258 zum Einbrennen in einem ROM 256 verwendet wird. Dieser ROM 256 kann dann auf eine Hardwarekarte zum Einsetzen in ein Gerät, wie ein unter Microsoft Windows CE betriebenes Handgerät, gesetzt werden, das die virtuelle Java-Maschine 260 und dem RAM 262 enthält.
Die Java-Klassendatei 252 sieht dieselben wie die Java-Klassendateien 202, die vorab geschrieben wurden; d. h., dass die Java-Klassendateien 252 diejenigen Klassendateien sind, die diejenigen enthalten, die zur Ausführung eines vorgegebenen Java-Programms erforderlich sind. Es ist zu beachten, dass alle erforderlichen Java-Klassendateien für ein vorgegebenes Java-Programm Teil der Java-Klassendateien 252 sein können; andere Java-Klassendateien können zur Laufzeit durch die virtuelle Java-Maschine 260 aus dem Speicher in den RAM 262 geladen und geparst werden, wie es für die Fig. 2(a) beschrieben wurde. Jedoch bilden wünschenswerterweise alle erforderlichen Klassendateien für ein vorgegebenes Java-Programm Teil der Java-Klassendateien 252, um optimale Ausfüh rungseffizienz zu erzielen.
Der Konverter 250 ist wünschenswerterweise ein Softwarewerkzeug (d. h. ein Computerprogramm), das für die Kombination von Klassendateien in eine einzelne DLL-Datei sorgt, wobei die DLL-Datei in portierbarem, ausführbarem (PE = portable executable) Format vorliegt, wie in der Technik bekannt. Das Werkzeug sorgt für die Spezifizierung der einzuschließenden individuellen Klassendateien (d. h. der Java-Klassendateien 252), und es sucht sich entlang einem spezifizierten Pfad durch alle abhängigen Klassendateien hindurch, wie es dem Fachmann bekannt ist. Wünschenswerterweise können auch DLL- Dateien in nativem Code zur Suche nach nativen Verfahren spezifiziert werden.
Der Konverter 250 lädt und parst Klassendateien auf dieselbe Weise wie eine virtuelle Java-Maschine, wie im Stand der Technik bekannt. Jedoch besteht wünschenswerterweise eine Ausnahme darin, dass der Konverter alle relevanten Datenstrukturen in speziellen Hiebs zuordnet, wobei alle Zeiger innerhalb dieser Datenstrukturen verfolgt werden, wie es dem Fachmann bekannt ist. Ferner platziert der Konverter wünschenswerterweise alle Strings in eine einzelne Stringtabelle, und native Mitgliedsfunktionen werden an die speziellen DLL-Dateien angepasst (d. h., dass DLL-Dateien zur Durchsuchung nach nativen Mitgliedfunktionen spezifiziert werden können; wenn eine an eine DLL-Datei angepasst ist, wird ein importierbarer Datensatz in der sich ergebenden DLL-Datei erzeugt, und die Datenstruktur der nativen Mitgliedsfunktion zeigt auf diesen Datensatz, wodurch eine spezielle und schnelle Auflösung nativer Mitgliedsfunktionen möglich ist). Bytecodes werden auch vom Big-Endian- auf das Little-Endian- Format umgestellt.
Das der Konverter zahlreiche Klassendateien in einer Sitzung vorab lädt und parst ist es wünschenswert, dazu in der Lage zu sein, nur eine Kopie von Daten einzuschließen, auf die sich mehr als eine Klassendatei stützt, so dass innerhalb der DLL-Datei 254 keine redundanten Daten vorhanden sind. Zum Beispiel können zwei Klassendateien auf dieselbe Superklasse Bezug nehmen, wie es in der Technik bekannt ist, so dass vollständige Information hinsichtlich dieser Superklasse in jeder Klassendatei vorhanden ist. Der Konverter enthält wünschenswerterweise nur eine Kopie dieser vollständigen Information, so dass jede Klasse auf dieselbe vollständige Information hinsichtlich der Superklasse Bezug nimmt. Dies ist ein Vorteil der Erfindung gegenüber dem Stand der Technik, wo das Laden einer Klassendatei zum Laden aller darin enthaltenen Information führt, unabhängig davon, ob sie betreffend andere Information von anderen Klassendateien redundant ist.
Die sich ergebende DLL-Datei 254, die im PE-Format vorliegt, verfügt über Datenabschnitte einschließlich der Hiebs von allen Klassendateien 252, sowie Bezugnahmen auf native Mitgliedsfunktionen, wie importierbare Datensätze, wie es beschrieben wurde. Alle Zeiger innerhalb dieser Abschnitte verfügen über eigene Ladezeit-Relokationsdatensätze, wie es dem Fachmann bekannt ist. Die Datei 254 wird wünschenswerterweise in den ROM 256 (oder einen anderen nichtflüchtigen Speicher) eingebrannt, um ein Laufzeitbild der Java-Klassendateien 252, wie vom Konverter 250 vorab geladen und geparst, zu erzeugen. Das Einbrennen in einem ROM erfolgt durch eine ROM-Bildeinbrenneinrichtung 258, die in der Technik bekannt ist. Zum Beispiel kann das Werkzeug ROM Image, bei dem es sich um ein OAK-Werzeug zu Windows CE handelt, verwendet werden. Wenn die DLL-Datei geladen wird, wird ein Zeiger auf das ROM-Bild erhalten, so dass keine zweite Kopie mehr geladen werden muss.
Die virtuelle Java-Maschine 260 ist wünschenswerterweise Software, die durch einen Prozess so von einem computer lesbaren Träger, wie einem Speicher, ausgeführt wird. Die virtuelle Java-Maschine, wie sie in der Technik bekannt ist, akzeptiert ein Kern-Befehlszeilenargument. Dieses Argument benennt die vertrauenswürdige (d. h. sichere) DLL-Datei der Kernklasse und verweist vorgabemäßig auf jcls.dll. Zur Laufzeit führt die virtuelle Java-Maschine einen Aufruf Load- Library und einen Aufruf GetProcAddress aus, um einen Zeiger auf die relevanten Datenstrukturen zu erhalten, und sie integriert diese mit existierenden Datenstrukturen in der virtuellen Java-Maschine. So ist die DLL-Datei der vertrauenswürdigen Kernklasse wünschenswerterweise das im ROM 256 abgespeicherte Laufzeitbild der Java-Klassendateien 252. Wenn neue Klassen von einem Java-Programm angefordert werden, wird die Klassenliste in der DLL-Datei der Kernklasse durchsucht, und wenn die neuen Klassen aufgefunden werden, wird die Klasseninitialisierung ausgeführt. Diese Klassen werden als initialisiert markiert und die Ausführung wird fortgesetzt. Dies umgeht die zeitaufwändige Prozedur des Ladens und Parsens der Klassendateien zur Laufzeit, wie dies beim Stand der Technik erfolgt. Es ist zu beachten, dass dann, wenn keine neue Klasse aufgefunden wird, im Dateisystem eine normale Suche nach der Klassendatei gestartet wird, und wenn sie aufgefunden wird, wird die Klasse wie beim Stand der Technik geladen und geparst.
In Zusammenhang mit dem Stand der Technik wurde ein Überblick über den Betrieb einer Ausführungsform der Erfindung auf Systemniveau beschrieben. Das vorab erfolgende Laden und Parsen von Java-Klassendateien durch ein Konverterprogramm bedeutet, dass das Laden und Parsen der Klassendateien nicht zur Laufzeit durch die virtuelle Java-Maschine erfolgen müssen, so dass Java-Programme effizienter laufen können. Ferner bedeutet das vorab erfolgende Laden und Parsen von Java- Klassendateien in ein in einer ROM-Einrichtung abgespeichertes Laufzeitbild, dass nur eine Version der Java-Klassendateien existiert - im Gegensatz zu zwei Versionen beim Stand der Technik (eine im Speicher und eine im RAM). Dies spart RAM in einem Gerät mit einer virtuellen Java-Maschine ein, was sehr gesucht sein kann.

Verfahren einer Ausführungsform der Erfindung

Im vorigen Abschnitt wurde eine Beschreibung des Betriebs einer Ausführungsform der Erfindung auf Systemebene gegeben. In diesem Abschnitt werden von einem Computer einer derartigen Ausführungsform, in der ein Konverter vorhanden ist, ausgeführte Verfahren unter Bezugnahme auf eine Reihe von Flussdiagrammen beschrieben. Die auszuführenden Verfahren bilden Computerprogramme aus computerausführbaren Anweisungen. Die Beschreibung von Verfahren unter Bezugnahme auf ein Flussdiagramm ermöglicht es dem Fachmann, Programme zu entwickeln, die Anweisungen zum Ausführen der Verfahren auf einem geeigneten Computer enthalten (dem Prozessor des Computers, der die Anweisungen von computerlesbaren Medien ausführt).
Es wird zunächst auf die Fig. 3(a) Bezug genommen, in der ein Flussdiagramm eines computergestützten Verfahrens gemäß einer Ausführungsform der Erfindung dargestellt ist. Dieses Verfahren enthält Schritte oder Aktionen, die von einem Gerät wie einem Computer ausgeführt werden müssen, um mindestens eine Java-Klassendatei vorab in ein Laufzeitbild zu laden und zu parsen, das in einem nichtflüchtigen Speicher wie einem ROM gespeichert wird. In einem Schritt 300 werden die Klassendateien vorab geladen und geparst, wie es in Zusammenhang mit der Fig. 2(b) beschrieben wurde, was auch in Verbindung mit der Fig. 3(b) beschrieben wird. In einem Schritt 302 wird von den vorab geladenen und geparsten Da teien ein Laufzeitbild erzeugt, wünschenswerterweise eine DLL-Datei in einem PE-Format, wie es in Zusammenhang mit der Fig. 2(b) beschrieben wurde. Schließlich wird, in einem Schritt 304, das Laufzeitbild - d. h., die DLL-Datei - in einen nichtflüchtigen Speicher wie einen ROM gebrannt, wie es ebenfalls in Zusammenhang mit der Fig. 2(b) beschrieben wurde. So umfasst das computergestützte Verfahren die folgenden drei Hauptschritte oder -aktionen: vorab erfolgendes Laden und Parsen der Klassendateien; Erzeugen einer Laufzeitbild- Datei; und Einbrennen der Laufzeitbild-Datei in einen nicht- flüchtigen Speicher.
Als Nächstes wird auf die Fig. 3(b) Bezug genommen, in der ein Flussdiagramm eines anderen computergestützen Verfahrens gemäß einer Ausführungsform der Erfindung dargestellt ist. Dieses Verfahren beinhaltet die Schritte oder Aktionen, die von einem Gerät wie einem Computer auszuführen sind, um eine Java-Klassendatei vorab zu laden und zu parsen. Das heißt, dass das Verfahren der Fig. 3(b) ein solches ist, durch das der Schritt 300 der Fig. 3(a) für jede der Java-Klassendateien ausgeführt wird. Der Fachmann erkennt, dass das Verfahren der Fig. 3(b) im Wesentlichen identisch mit der Lade- und Parsmethode ist, wie sie von einer in der Technik bekannten virtuellen Java-Maschine ausgeführt wird. Demgemäß ist die Beschreibung des Verfahrens der Fig. 3(b) mit ausreichenden Einzelheiten versehen, um den Fachmann in die Lage zu versetzen, die Erfindung auszuführen und zu nutzen.
In einem Schritt 350 wird die Klasse aus der Klassendatei geladen, und die Klasse wird in einem Schritt 352 geparst. Dies beinhaltet das Parsen des Konstantenpools, das Parsen der Methoden, das Parsen der Felder, das Parsen der Interfaces und der Parsen der Attribute der Klasse. Die Klassenreferenzen ausgehend vom Klassenpool werden zur Liste von Klassen für den Ladevorgang in einem Schritt 354 hinzuge fügt. Dann wird in einem Schritt 356 das Laden der Klassen fortgesetzt, bis die Klassenliste leer ist. Schließlich wird in einem Schritt 358 eine Relokationsinformation in die DLL- Datei eingeschrieben (was eine Korrektur irgendwelcher Fehler innerhalb des Konstantenpools beinhalten kann).
Wenn jede Klassendatei durch das Verfahren der Fig. 3(b) verarbeitet wird, werden Daten, die in einer Klassendatei angetroffen werden, die mit solchen redundant sind, wie sie in einer zuvor verarbeiteten Klassendatei abgespeichert wurden, nicht erneut abgespeichert. Vielmehr wird auf die bereits abgespeicherten Daten verwiesen, so dass das sich ergebende Laufzeitbild wünschenswerterweise nur nicht-redundante Daten enthält. Ferner besteht, da Java-Klassendateien typischerweise Daten im Bit-Endian-Format enthalten, wie bereits beschrieben, ein Gesichtspunkt des Vorablade- und Vorabparsprozesses der Fig. 3(b) in der Umwandlung der Daten im Big-Endian-Format in solche im Little-Endian-Format.
Es wurden Verfahren gemäß einer Ausführungsform der Erfindung beschrieben. Zu diesen Verfahren gehört das Verfahren, gemäß dem Klassendateien vorab geladen und geparst werden, ein Assembeln in ein Laufzeitbild erfolgt und sie in einen ROM eingespeichert werden. Zu den Verfahren gehört auch das Verfahren, gemäß dem die Schritte oder Aktionen genau abgegrenzt wurden, die bei einer Ausführungsform der Erfindung dazu erforderlich sind, eine Klassendatei tatsächlich vorab zu laden und zu parsen, was im Wesentlichen mit denjenigen Schritten identisch ist, wie sie von einer virtuellen Java- Maschine ausgeführt werden, wenn eine Klassendatei zur Laufzeit geladen wird.

Schlussfolgerung

Es wurde das Kombinieren mehrerer Java-Klassendateien in ein Laufzeitbild beschrieben. Obwohl hier spezielle Ausführungsformen veranschaulicht und beschrieben wurden, ist vom Fachmann zu beachten, dass jegliche Anordnung, die so berechnet ist, dass sie denselben Zweck erfüllt, die angegeben speziellen Ausführungsformen ersetzen kann. Diese Anwendung soll jegliche Anpassungen oder Variationen der Erfindung abdecken. Zum Beispiel kann auch während die Klassendatei während der Erzeugung der vorab zu ladenden DLL-Datei geparst werden, Java-Bytecode auch in native Code kompiliert werden, und es kann auch dieser native Code in der DLL-Datei gespeichert werden. Dies ist der auf einer typischen virtuellen Java-Maschine ausgeführten Just-in-time(JIT)-Interpretation vergleichbar, hätte jedoch statt dessen den Effekt des vorab Interpretierens des Codes, so dass später beim Ausführen der JIT-Interpretation zur Laufzeit keine Zeit vergeudet wird. So ist es ausdrücklich vorgesehen, dass die Erfindung nur durch die folgenden Ansprüche und deren Äquivalente beschränkt ist.

Claims

1. Computergerät mit

einer Ausführungsvorrichtung (21, 260) zum Ausführen einer Java-Applikation mit Bezügen zu einer oder mehreren Java-Klassen,

dadurch gekennzeichnet, dass

das Gerät weiterhin umfasst:

eine Speichervorrichtung (304) zum Speichern eines Laufzeitbilds (256), das eine Bibliothek von vorab geladenen, vorab geparsten Java-Klassen aufweist, und

wobei die Ausführungsvorrichtung umfasst:

eine Vorrichtung, um der Java-Applikation mit Bezügen zu einer oder mehreren Java-Klassen direkten Zugang zu mindestens einer der Java-Klassen innerhalb des Laufzeitbilds zu geben.

2. Gerät nach Anspruch 1, wobei die Ausführungsvorrichtung (21, 260) umfasst:

einen Prozessor (21); und

eine virtuelle Java-Maschine (260), die durch den Prozessor (21) ausführbar ist, und so betreibbar ist, dass Java- Applikationen mit Bezügen zu einer oder mehreren Java-Klassen ausführbar sind.

3. Gerät nach Anspruch 2 mit weiterhin einer Vorrichtung zum Lesen eines computerlesbaren Mediums, wobei die virtuelle Java-Maschine (260) eine Software umfasst, die durch diese Vorrichtung gelesen wird.

4. Gerät nach einem der vorhergehenden Ansprüche, wobei die Speichervorrichtung (304) einen nichtflüchtigen Speicher umfasst.

5. Gerät nach Anspruch 4, wobei der nichtflüchtige Speicher einen Read-Only-Speicher (24) umfasst.

6. Gerät nach einem der vorhergehenden Ansprüche, wobei die Speichervorrichtung (304) derart betreibbar ist, dass vorab geladene und vorab geparste Java-Klassen in einem portierbaren ausführbaren Format speicherbar sind.

7. Gerät nach einem der vorhergehenden Ansprüche, wobei die Speichervorrichtung (304) derart betreibbar ist, dass ein nicht redundante Daten umfassendes Laufzeitbild (256) von mindestens einer Java-Klassen-Datei (252) speicherbar ist.

8. Gerät nach einem der vorhergehenden Ansprüche, wobei das Speichermedium (304) derart betreibbar ist, dass ein Laufzeitbild (256) in Form einer einzigen dynamisch verlinkten Bibliotheksdatei speicherbar ist.

9. Verfahren zum Ausführen einer Java-Applikation mit Bezügen zu einer oder mehreren Java-Klassen, folgende Schritte umfassend:

Speichern eines vorab geladenen und vorab geparsten Laufzeitbilds (256) mindestens einer Java-Klassen-Datei (252) mit einer Klasse, wobei das vorab geladene und vorab geparste Laufzeitbild (256) eine Bibliothek von vorab geladenen und vorab geparsten Java-Klassen umfasst; und

während der Laufzeit, Ausführen einer Java-Applikation mit Bezügen zu einer oder mehreren benötigten Java-Klassen, wobei die Java-Applikation auf mindestens eine der Java-Klassen innerhalb des vorab geladenen und vorab geparsten Laufzeitbilds (256) zugreift, ohne die Java-Klassen innerhalb des vorab geladenen und vorab geparsten Laufzeitbilds (256) zu laden oder zu parsen.

10. Verfahren nach Anspruch 9, wobei das vorab geladene und vorab geparste Laufzeitbild (256) vor der Laufzeit erzeugt wird, und wobei das Erzeugen des vorab geladenen und vorab geparsten Laufzeitbilds (256) für jede Java-Klasse (252) mit einer Klasse umfasst:

i) Laden (35) der Klasse;

ii) Analysieren (352) eines Konstanten-Pools, wobei der Pool mindestens eine Superklasse (3) umfasst;

iii) Laden (350) jeder Superklasse;

iv) Parsen (352) mindestens einer Methode aus der Klasse; und

v) Parsen (352) mindestens einer Eigenschaft aus der Klasse.

11. Verfahren nach Anspruch 10, wobei das Erzeugen des vorab geladenen und vorab geparsten Laufzeitbilds (256) weiterhin umfasst:

(vi) Korrigieren von Fehlern innerhalb des Konstantenpools.

12. Verfahren nach einem der Ansprüche 9 bis 11, wobei das vorab geladene und vorab geparste Laufzeitbild (256) mindestens einer Java-Klassen-Datei (252) nur nicht-redundante Daten umfasst.

13. Verfahren nach Anspruch 12, wobei das Erzeugen des vorab geladenen und vorab geparsten Laufzeitbilds (256) umfasst, dass ein vorab geladenes und vorab geparstes Laufzeitbild (256) mehrerer Java-Klassen-Dateien (252) erzeugt wird und wobei die mehreren Java-Klassen-Dateien Bezüge zu der gleichen Superklasse umfassen, und wobei in dem vorab geladenen und vorab geparsten Laufzeitbild (256) eine einzige Darstellung von Informationen für die Superklasse enthalten ist.

14. Verfahren nach einem der Ansprüche 9 bis 13, wobei die mindestens eine Java-Klassen-Datei (252) Daten im Big-Endian- Format umfasst, und wobei das vorab geladene und vorab geparste Laufzeitbild (256) Daten im Little-Endian-Format umfasst.

15. Verfahren nach einem der Ansprüche 9 bis 14, wobei der Schritt des Speicherns des vorab geladenen und vorab geparsten Laufzeitbilds (256) das Speichern eines vorab geladenen und vorab geparsten Laufzeitbilds als dynamisch verlinkte Bibliotheks-Datei umfasst.

16. Verfahren nach einem der Anspruche 9 bis 15, wobei der Schritt des Speicherns des vorab geladenen und vorab geparsten Laufzeitbilds (256) das Speichern des vorgeladenen und vorab geparsten Laufzeitbilds (256) in einem portierbaren, ausführbaren Format umfasst.

17. Computerlesbares Medium mit einem darauf gespeicherten Computerprogramm, das ausführbar ist, um einen programmierbaren Computer dazu zu veranlassen, ein Verfahren nach einem der Ansprüche 9 bis 16 auszuführen.