-
Gebiet der vorliegenden Offenbarung
-
Die
vorliegende Offenbarung betrifft im Allgemeinen Techniken zum Betreiben
eines elektronischen Geräts,
das zumindest eine zentrale Recheneinheit aufweist, auf der Grundlage
einer plattformunabhängigen
Software, wobei die Plattform durch eine virtuelle Maschine bereitgestellt
wird, die eine standardmäßige Hardwareumgebung
simuliert.
-
Beschreibung des Stands der
Technik
-
Der
ständige
Fortschritt auf dem Gebiet der Halbleiterherstellung führte zur
Herstellung schneller und leistungsfähiger integrierter Schaltungen,
die Millionen einzelne Transistorelemente enthalten können. Folglich
wurden sehr komplexe Digitalschaltungen entwickelt und wurden verwendet
zum Gestalten zum Herstellen komplexer zentraler Recheneinheiten (CPU),
wobei die erhöhte
Packungsdichte in Verbindung mit einer geringeren Leitungsaufnahme
und einer hohen inneren Speicherkapazität eine Vielzahl von Entwicklungen
beim Integrieren komplexer CPU's
in eine breite Fülle
elektronischer Geräte
beschleunigt hat. Folglich besitzen nicht nur Computersysteme eine
bessere Leistungsfähigkeit
im Hinblick auf die Arbeitsgeschwindigkeit und Leistungsaufnahme,
sondern auch eine Vielzahl anderer elektronischer Geräte, etwa
mobile Geräte
in Form von Computern, Bildtelefonen und dergleichen, bieten bemerkenswerte
Rechenleistungen. Mit der Verbreitung von Computersystemen und anderen
elektronischen Geräten
wurde daher auch eine entsprechende Nachfrage nach komplexe Anwendungen
erzeugt, diese besteht weiterhin.
-
Typischerweise
wird eine CPU auf der Grundlage einer speziellen Bytecodierung oder
Maschinencodierung betrieben, die zu einer entsprechenden Änderung
des Zustands von Hardwarekomponenten, etwa von Registern, I/O-(Eingabe/Ausgabe)Anschlüssen und
dergleichen gemäß der Sequenz
aus Maschinencodierungsbefehlen führt. Daher muss auf der tiefsten
Ebene einer Kommunikation zwischen einer Nutzanwendung und dem Gerätesystem
mit der CPU die entsprechende Sequenz aus Bytecodierungsbefehlen
von der CPU ausgeführt werden,
wodurch die gewünschten
Ergebnisse in Form von Registerinhalten und dergleichen bereitgestellt
werden. Die Entwicklung einer entsprechenden mehr oder weniger komplexen
Sequenz aus Maschinencodierungsbefehlen kann sehr zeitaufwendig sein
und kann auch spezielle Fertigkeiten beim „Übersetzen” eines entsprechenden Problems
oder einer Aufgabe, die von einer speziellen Anwendung zu lösen ist,
in eine Sequenz aus Maschinencodierungsbefehlen erfordern. Das Entwickeln
eines Maschinencodeprogramms, das für die Erfüllung einer speziellen Anwendung
geeignet ist, hängt
eng mit der Konfiguration des verwendeten Gerätesystems ab, d. h. der speziellen
CPU in Verbindung mit anderen Komponenten, etwa einem externen Arbeitsspeicher, Buskonfiguration
und dergleichen, so dass ein Maschinencodeprogramm, das für eine spezielle
Hardwarekonfiguration bereitgestellt wird, nicht auf einem anderen
Hardwaresystem einsetzbar ist. Aus diesen Gründen wurden Programmiersprachen
entwickelt, um die Kommunikation zwischen dem Programmentwickler
und dem Gerätesystem
zu vereinfachen, in welchem die entsprechende Anwendung abzuarbeiten
ist. Beispielsweise bildete die Einführung von Assembler-Sprachen einen deutlichen
Fortschritt, um eine höhere
Abstraktionsebene bereitzustellen und festzulegen im Vergleich zu
der grundlegenden Maschinenbytecodierung. In weiteren Versuchen
zur Erhöhung
der Abstraktionsebene wurden höhere
Programmiersprachen entwickelt, um eine geeignete Plattform für die Erzeugung
von Quellencodierungen entsprechend einer speziellen Aufgabe bereitzustellen,
wobei diese Codierung dann in eine entsprechende Maschinenleitcodierung übersetzt
wird, die von dem Mikroprozessor des Computersystems verstanden
und damit ausgeführt
werden kann. In diesen höheren
Programmiersprachen müssen
gewisse Schlüsselwörter verwendet
werden entsprechend der sprachspezifischen „Grammatik”, wodurch eine Sequenz aus
Programmschritten definiert werden kann, um die erforderlichen Ergebnisse
zu erhalten.
-
Gemäß einer
Vorgehensweise bei der Entwicklung höherer Programmiersprachen wurde
die sogenannte objektorientierte Programmierung eine häufig eingesetzte
Technik, in der versucht wird, alltägliche Lebenssituationen in
angenehmerer Weise in einen Computerprogramm zu übertragen. D. h., gemäß objektorientierten
Ansatz werden spezielle Objekte und Klassen definiert, dass diese
grundlegende Eigenschaften besitzen, die auf gewisse Ereignisse
in einer vordefinierten Weise reagieren. Damit können sehr komplexe Anwendungen
erzeugt werden, wobei entsprechende Objekte in unterschiedlichen
Anwendungen in sehr effizienter Weise wiederholt verwendet werden
können,
wodurch die wiederholte Entwicklung der gleichen Software vermieden
wird.
-
Obwohl
höhere
Programmiersprachen für eine
effiziente Plattform zum Entwickeln einer Vielzahl von Anwendungen
sorgen, macht die breite Fülle
verfügbarer
Geräteplattformen,
d. h. unterschiedlicher Mikroprozessorarten, Computersystemarchitekturen
und dergleichen, dennoch eine spezielle Anpassung der Anwendungen
an die Zielarchitektur erforderlich. Auf Grund dieser Situation
wurden Sprachen dahingehend entwickelt, um die Möglichkeit zu bieten, plattformunabhängige Anwendungen
zu entwickeln, in denen der Softwareentwickler sich durch die Anwendung
selbst konzentrieren kann, ohne dass gerätespezifische Eigenschaften
entsprechender Computersysteme berücksichtigt werden müssen. Die
Nachfrage nach plattformunabhängigen
Anwendungen wird ferner durch die Tatsache verstärkt, dass eine Vielzahl computerbasierter
elektronischer Geräte
heutzutage verfügbar
sind, die Rechenleistung bereitstellen, die die Verbreitung einer
Vielzahl von Anwendungen ermöglichen.
Da elektronische Geräte,
Mobiltelefone, tragbare Computer und dergleichen sich in ihrer Gerätekonfiguration
deutlich voneinander unterscheiden können, ermöglicht eine Plattform unabhängige Anwendungen
der Entwicklung von Anwendungen, die schließlich einer beliebigen Art
an elektronischen Geräten
abhängig
von der speziellen Hartwarearachitektur einsetzbar sind.
-
Des
weiteren ist eine ständig
anwachsende Anzahl an Computersystemen mittels geeignete Netzwerke
verbindbar, etwa mit dem Internet, wobei dies auf der Grundlage
von drahtlosen oder kabellosen geschützten Netzwerksystemen erfolgt,
so dass Anwendungen einen Anwender über das Netzwerk zugeleitet
werden können,
wobei die Gerätekonfiguration
eines speziellen Zielsystems nicht im vorhinein bekannt ist.
-
Das
Konzept des Bereitstellens plattformunabhängiger Anwendungen beruht eigentlich
auf das Einführen
eines „virtuellen” Computersystems
oder eine virtuelle Maschine, die auf Basis einer speziellen virtuellen
Bytecodierung betrieben wird, die von der plattformunabhängigen Anwendung
bereitgestellt wird. Somit simuliert die virtuelle Maschine eigentlich eine
Gerätekonfiguration
und dient damit als eine Schnittstelle zwischen der plattformunabhängigen Anwendung
und der speziellen Gerätekonfiguration. Es
sind daher eine Vielzahl virtueller Maschinen verfügbar, die
eine Standardplattform für
das Ausführen von „plattformunabhängigen” Anwendungen
bereitstellen, wobei sich eine Schnittstelle mit speziellen Gerätekonfigurationen
in Verbindung mit zugehörigen
Betriebssystemen bereitstellen. Wenn folglich eine geeignete virtuelle
Maschine auf einem Computersystem installiert wird oder in einem
anderen elektronischen Gerät
kann eine Anwendung entwickelt und von der virtuel len Maschine unabhängig von
Gerätekonfiguration
ausgeführt
werden. Beispielsweise repräsentiert
die Programmiersprache JAVA von Sun Mircosystems eine objektorientierte
Sprache, in der Anwendungen effizient programmiert werden können, ohne
dass eine Anpassung an unterschiedliche Betriebssysteme der speziellen
Computerplattformen erforderlich ist. Wenn ein Anwender ein JAVA-Programm
startet, wird automatisch die virtuelle JAVA-Maschine gestartet
und diese lädt
entsprechende Klassendateien, die dann übersetzt werden, um die „Maschinencodierung” der virtuellen
Maschine zu erzeugen. Wenn weitere Klassen zum Ausführen der
betrachteten Anwendung erforderlich sind, werden diese Klassen nach
Bedarf während
der Laufzeit eingeladen und werden ebenfalls nach Bedarf übersetzt.
Beispielsweise sind viele Klassen für die virtuelle Maschine verfügbar und
können
in eine entsprechende Bibliothek integriert werden. Während des
Betriebs der virtuellen Maschine führt somit die eigentliche CPU
die Maschinencodierung, die der virtuellen Maschine entspricht,
aus, wodurch Speicher zum Speichern des Zustand des Prozessors, beispielsweise
in Form von IRQ (Interrupt-Anforderungs-)Adressen und dergleichen
erforderlich ist. Somit werden der Prozessor, die Maschinencodierung und
der Zustand des Speichers die virtuelle Maschine. Andererseits führt die
virtuelle Maschine die Anwendung entsprechend dem kompirierten Programm der
Anwendung aus, wodurch ebenfalls ein spezieller Zustandsspeicher
erforderlich ist, in welchem entsprechende Informationen der virtuellen
Maschine gespeichert werden. Beispielsweise wird eine Tabelle der
Vision von Klassen, die gleichzeitig in der virtuellen Maschine
vorhanden sind, gespeichert. Die virtuelle Maschine, das darin eingeladene
Programme und der entsprechende virtuelle spezielle Zustandsspeicher
realisieren somit die tatsächliche
Anwendung. Beispielsweise sind in der JAVA-Spezifikation für die virtuelle Maschine das
Format von Eingaben angegeben, d. h. der Klassendateien, und es
ist auch gegeben, wie die Klassendateien zu übersetzen sind. Jedoch ist,
wie zuvor erläutert
ist, nicht explizit spezifiziert, wie die Übersetzung einzurichten ist.
Folglich wird ein unabhängig
arbeitendes Plattformsystem bereitgestellt, so dass die JAVA-Anwendung
nicht relevant ist, ob diese auf ein LINUX-System, einem Windows-System oder einer
anderen Art an Betriebssystem ausgeführt wird, solange eine spezielle virtuelle
Schiene für
diese Plattformen installiert ist.
-
Die
gewünschte
Plattform unabhängige Funktionsfähigkeit
der JAVA-Anwendungen wird auf die folgende Weise verwirklicht. Die
Eingabe für
die virtuelle JAVA-Maschine bzw. die Klassendateien enthalten Information über die
gewünschte
Anwendung. Die Klassendateien besitzen eine speziellen Aufbau, der
durch eine Vielzahl von Abschnitten bestimmt ist, die die erforderliche
Information, etwa Einträge
für Konstante,
Verfahren und Feldbeschreibung, Codierungs- und Fehlerverfolgungsinformation und
dergleichen enthalten. Beim Einladen und Übersetzen einer entsprechenden
Klassendatei wird daher diese in diesen standardmäßigen Abschnitten enthaltene
Information verwendet, um die Klassendatei für das Ausführen für die virtuelle Maschine zu verifizieren
und vorzubereiten.
-
Grundsätzlich kann
eine Klasse als eine Repräsentation
einer Vielzahl ähnlicher
Objekte verstanden werden, die Attribute und Methoden besitzen.
Ein Attribut kann als eine Konstante oder eine Variable einer speziellen
Type verstanden werden. Eine Methode kann als eine „Funktion” betrachtet werden,
die somit eine Sequenz der Prozessschritte repräsentiert, die durch eine Quelle
aus Bytecodierungen, d. h. Maschinenbefehlen der virtuellen Maschine
repräsentiert
sind, die auszuführen
sind, um eine spezielle Programmsequenz zu bilden. Die Bytecodierung
der virtuellen Maschine repräsentiert eine ähnliche
Abstraktionsebene wie ein Assembler-Befehl, wie dies zuvor erläutert ist.
Somit sind für jede
Methode entsprechende lokale Variablen in Verbindung mit zusätzlicher
Information im Hinblick auf die maximale Größe des erforderlichen Speicherbereichs
und desgleichen zu speichern. Auf Grund der objektorientierten Natur
der Sprache werden die ferner die Klassenmethoden und Attribute
von anderen Klassen erben, die somit ebenfalls in den standardmäßigen Abschnitten
der betrachteten Klasse zu speichern sind. Ferner sind Sicherheitsinformationen und
Informationen für
die Ausnahmebehandlung und für
die Fehlerverfolgung in den standardmäßigen Abschnitten vorzusehen.
Ferner umfasst die virtuelle Schiene einen Klassenlader, der für das „Konvertieren” der Klasseninformation,
die extern in Klassendateien gespeichert ist, in den Strukturen
während
der Laufzeit. Zu diesem Zweck verifiziert der Klassenlader die Konsistenz
der betrachteten Klasse, beispielsweise im Hinblick auf das identifizieren,
dass jeder Teil der Datei durch das Programm aufgerufen werden kann,
und dergleichen. Wenn die Verifizierung abgeschlossen ist, ohne
dass Fehler erkannt werden, lädt
der Klassenlader die Information in die virtuelle Maschine ein und
ruft die Bytecode-Ausführungseinheit
der virtuellen Maschine auf. Die Ausführungseinheit der virtuellen
Maschine ist für
das Ausführen
von Methoden auf der Grundalge von Bytecodierung verantwortlich,
wie dies zuvor beschrieben ist. Wenn ein Befehl zum Erzeugen einer
Version einer entsprechenden Klasse angetroffen wird, erkennt die
Bytecodeausführungseinheit,
ob die Klasse bereits geladen ist oder nicht. Folglich werden entsprechende
Klassendateien in die virtuelle Maschine auf Anforderung während der
Laufzeit eingeladen, wobei entsprechende Klassendatei durch eine
beliebige Quelle bereitgestellt werden, etwa als lokaler Speicher
betrachteten Plattform, durch einen entfernten Computer und dergleichen.
-
Obwohl
das Merkmal der Unabhängigkeit der
virtuellen Maschine von einem speziellen Betriebssystem und einer
Gerätekonfiguration
sehr vorteilhaft ist für
viele Anwendungen, kann es dennoch vorteilhaft sein, plattformspezifische „Methoden” einzubauen,
um spezielle Eigenschaften der Plattform auszunutzen, wodurch das
Leistungsvermögen
einer entsprechenden Anwendung verbessert wird, ein Aufwand im Hinblick
auf die Zeit für
die Entwicklung spezieller Anwendungen verkürzt wird oder dergleichen.
In diesem Falle kann die Klassendatei eine Referenz bzw. Zeiger
zu einer „nativen
Methode” enthalten,
die als ein plattformspezifischer Satz aus Befehlen verstanden werden
kann, die zum Ausführen
einer gewissen Sequenz aus Programmschritten mit hoher Effizienz
auf der Grundlage plattforminterner Ressourcen bezeichnet ist. Entsprechende
native Methoden werden typischerweise in Form von geeigneten Bibliotheken,
etwa dynamische Verbindungsbibliotheken (DLL), die in Betriebssystem
Window benutzt werden, oder in sogenannten gemeinsamen Bibliothek
bereitgestellt werden, wie beispielsweise in Betriebssystem LINUX
verwendet werden. Eine Referenzierung einer entsprechenden Anforderung
einer nativen Methode ist die entsprechende Bibliothek, die zum
Abarbeiten der Anforderung erforderlich ist, in geeigneter Weise
von dem Anwender „gepackt” werden,
so dass die erforderlichen Bibliotheken während der Laufzeit der Anwendung
in dem Bibliothekenpfad der Anwendung enthalten sind, um damit entsprechende
Laufzeitfehler zu vermeiden, wenn die angeforderte Bibliothek nicht
verfügbar
ist. Ferner kann häufig
ein Konflikt auftreten, wenn unterschiedliche Versionen von Klassen
unterschiedliche Versionen der nativen Codierung erfordern, die
eine entsprechende native Methode repräsentieren, die durch unterschiedliche
native Codebibliotheken bereitzustellen ist. In diesem Falle benutzt
häufig
jede Version der Klasse zum Erfüllen
der Anforderung für die
native Methode den gleichen Bibliothekspfad, das ebenfalls zu einem
entsprechenden Laufzeitfehler führen
kann. Folglich kann die Entwicklung von JAVA-Anwendungen, die den
Einbau nativer Methoden erfordern, zeitaufwendig und fehlerbehaftet
sein, wodurch diese Vorgehensweise, d. h. die Verwendung plattforminterner
Ressourcen, wenig attraktiv ist.
-
Angesichts
der zuvor beschriebenen Situation betrifft die vorliegende Offenbarung
Systeme und Verfahren, in denen native Methoden effizient in einer ansonsten
plattformunabhängi gen
Anwendung eingesetzt werden können,
wobei eines oder mehrere der oben erkannten Probleme vermieden oder
zumindest in der Auswirkung reduziert werden.
-
Überblick über die Offenbarung
-
Im
Allgemeinen betrifft die vorliegende Offenbarung Techniken und Systeme,
in denen eine native Codierung effizient in einer Anwendungsdatei, die
von einer virtuellen Maschine auszuführen ist, eingesetzt werden
kann. Zu diesem Zweck wird ein Mechanismus angewendet, in welchem
die native Codierung in die Anwendungsdatei, eine JAVA-Klassendatei,
eingebettet wird, und die als Bibliothek verwendet wird, wenn eine
Anforderung für
eine native Methode in der Anwendungsdatei erkannt wird. Zu diesem
Zweck wird in einigen anschaulichen hierin offenbarten Ausführungsformen
die eingebettete native Codierung in geeigneter Weise in der Klassendatei „versteckt” werden,
so dass diese von der virtuellen Maschinen ignoriert wird, wenn
diese die virtuelle maschinenspezifischen Bytecodierungen der Anwendungsdatei
ausführt.
Andererseits wird beim Vorbereiten der Anwendungsdatei für das Ausführen durch
die virtuelle Maschine die ansonsten „versteckte” eingebettete
native Codierung möglicherweise
in Verbindung mit zusätzlichen
Informationen zum Verwalten der eingebetteten nativen Codierung
und dergleichen als eine Basis verwendet, um eine Anforderung für eine native
Methode abzuarbeiten, die in dem eigentlichen speziellen Befehlen
für die
virtuelle Maschine erkannt wird. Beispielsweise wird die eingebettete
native Codierung in die für
die virtuelle Maschine verfügbaren
Speicherbereich kodiert und wird dann für Operationen zum Auffinden
einer Bibliothek der betrachteten Anwendung verwendet. Folglich können entsprechende
hohe Aufwendungen für
das Hinzufügen
von Abhängigkeiten
in Bezug auf native Methoden zu dem Datei-Pfad der virtuellen Maschine,
beispielsweise zu dem Klassenpfad einer virtuellen JAVA-Maschine,
und auch für
das Ändern
des Bibliothekspfads der Anwendung zur Sicherstellung, dass angesprochene
native Codebibliothek ebenfalls für die virtuelle Maschine verfügbar ist,
vermieden werden. Des weiteren können
auch andere Alternativen, etwa das Kopieren der betrachteten Bibliothek nativer
Codierung in ein Verzeichnis, das als gegenwärtig zulässiger Pfad bekannt ist, vermieden
werden, so dass die Gefahr der Kollision von Bibliotheken in diesem
begrenzten Namensbereich entlang dem Bibliothekenpfad ebenfalls
vermieden wird. Folglich wird ein anwenderfreundlicher Mechanismus bereitgestellt,
in welchem der Grad der Plattformunabhängigkeit der zu einem gewissen
Grade durch die Notwendigkeit beschränkt wird, dass Plattformen
für die
Verfügbarkeit
der Bibliothek mit nativer Codierung sorgen, wieder her gestellt
wird, indem das native Codierungssegment oder die Bibliothek möglicherweise in
Verbindung mit zusätzlicher
Information innerhalb einer Klassendatei bereitgestellt und indem
die Möglichkeit
geschaffen wird, eine Referenz zu einer nativen Methode zu erkennen
und eine eingebettete native Codierung zum Abarbeiten entsprechender
Anforderungen zu verwenden.
-
Ein
anschauliches hierin offenbartes elektronisches Gerät umfasst
ein Hardwaresystem mit einer zentralen Recheneinheit (CPU), einem
Speicher und einem Bussystem, das die zentrale Recheneinheit mit
dem Speicher verbindet. Des weiteren wird in dem Hardwaresystem
implementierte virtueller Maschinenbefehlssatz bereitgestellt und
diese ist ausgebildet, eine virtuelle Maschine zum Übersetzen
anwendungsspezifischer Befehle in eine Breitcodierung, die spezifisch
für die
virtuelle Maschine ist, zu übersetzen
und die Breitcodierung, die für
die virtuelle Maschine spezifisch ist, auszuführen. Ferner umfasst das elektronische
Gerät eine
Anwendungsdatei, die einen Satz anwendungsspezifischer Befehle enthält, die
in die Breitcodierung, die für
die virtuelle Maschine spezifisch ist, zu übersetzen sind, wobei der Satz
aus anwendungsspezifischen Befehle eine Anforderung für eine native
Methode enthält.
Des weiteren enthält
die Anwendungsdatei ein eingebettetes natives Codierungssegment,
das zum Abarbeiten der Anforderung beim Ausführen der Anwendungsdatei in
der virtuellen Maschine verwendet wird.
-
Ein
anschauliches hierin offenbartes Verfahren betrifft das Ausführen von
Befehlen in einer virtuellen Maschine, die in einem Hardwaresystem
eingebettet ist, das zumindest eine zentrale Recheneinheit aufweist.
Das umfasst das Bereitstellen einer Anwendungsdatei mit plattformunabhängigen Befehlen,
die in eine virtuelle maschinenspezifische Breitcodierung übersetzbar
sind, die von der virtuellen Maschine ausführbar ist, wobei die Anwendungsdatei
ferner eine eingebettete native Codierung enthält, die gestaltet ist, das
Ausführen
nativer Methoden in dem Hardwaresystem zu ermöglichen. Ferner umfasst das
Verfahren das Suchen nach einer Anforderung für eine native Methode in den
plattformunabhängigen
Befehlen und das Abarbeiten der Anforderung auf der Grundlage der
eingebetteten nativen Codierung, wenn die eingebettete native Codierung
eine Implementierung der nativen Methode für das Hardwaresystem umfasst.
-
Ein
anschauliches hierin offenbartes Speichermedium umfasst eine Anwendungsdatei
auf der Grundlage computerlesbaren Information. Die Anwendungsdatei
umfasst einen Satz aus plattformunabhängigen Befehlen, in Bytecodierung
ersetzbar sind, die in einer virtuellen Maschine ausführbar ist, die
auf einem Hardwaresystem mit einer CPU installiert ist, wobei der
Satz aus plattformunabhängigen Befehlen
eine Anforderung für
eine native Methode enthält,
die auf der Grundlage eines hardwarespezifischen Befehlssatzes auszuführen ist.
Des weiteren umfasst die Anwendungsdatei des Speichermediums eine
Bibliothek mit nativer Codierung mit zumindest einer Implementierung
der native Methode.
-
Ein
weiteres anschauliches offenbartes Speichermedium umfasst eine Datendatei
auf der Grundlage von computerlesbarer Information. Die Datendatei
umfasst einen Satz aus plattformunabhängigen Befehlen, die in Bytecodierung
ersetzbar sind, die von einer auf einem Hardwaresystem mit einer
CPU installierten virtuellen Maschine ausführbar sind, wobei der Satz
aus plattformunabhängigen
Befehlen die virtuelle Maschine veranlasst, die folgenden Aktionen
auszuführen.
Erkennen einer Anwendungsdatei, die von der virtuellen Maschine
angefordert wird, Einladen der Anwendungsdatei in die virtuelle
Maschine und suchen nach einer Anforderung für eine native Methode, die
in dem plattformunabhängigen
Befehlssatz, der in der Anwendungsdatei bereitgestellt wird, enthalten
ist, und suchen nach einer eingebetteten Bibliothek mit nativer
Codierung in der Anwendungsdatei beim Erkennen der Anforderung für die native
Methode.
-
Kurze Beschreibung der Zeichnungen
-
Weitere
Ausführungsformen
der vorliegenden Offenbarung sind in den angefügten Patentansprüchen definiert
und gehen deutlicher aus der folgenden detaillierten Beschreibung
hervor, wenn diese mit Bezug zu den begleitenden Zeichnungen studiert
wird, in denen:
-
1a schematisch
eine Darstellung einer Hardwarekonfiguration zeigt, die ein elektronisches Gerät, ein Computersystem
und dergleichen repräsentiert,
in welchem eine virtuelle Maschine mit einem Mechanismus zum Handhaben
der Anforderung für
native Methoden auf der Grundlage einer nativen Codierung installiert
ist, die in eine Anwendungsdatei gemäß anschaulicher Ausführungsformen
eingebettet ist;
-
1b schematisch
ein Beispiel der Dateistruktur mit eingebettetem nativen Codierungssegmenten
gemäß anschaulicher
Ausführungsformen
zeigt;
-
1c schematisch
einen Teil einer virtuellen Maschine, die geeignet gestaltet ist,
um eingebettete native Codierungssegmente zu handhaben, beispielsweise
in Form eines modifizierten Klassenladers einer JAVA-Umgebung; und
-
1d schematisch
einen Mechanismus zeigt, der in der virtuellen Maschine zur Handhabung von
Anforderungen für
native Methoden beispielsweise auf der Grundlage des modifizierten
Klassenladers aus 1c gemäß noch weiterer anschaulicher
Ausführungsformen
zeigt.
-
Detaillierte Beschreibung
-
Obwohl
die vorliegende Offenbarung mit Bezug zu den Ausführungsformen
beschrieben ist, wie sie in der folgenden detaillierten Beschreibung
sowie in den Zeichnungen dargestellt sind, sollte beachtet werden,
dass die folgende detaillierte Beschreibung sowie die Zeichnungen
nicht beabsichtigen, die vorliegende Offenbarung auf die speziellen
offenbarten Ausführungsformen
einzuschränken,
sondern die beschriebenen Ausführungsformen
stellen lediglich beispielhaft die diversen Aspekte des hierin offenbarten Gegenstands
dar, dessen Schutzbereich durch die angefügten Patentansprüche definiert
ist.
-
Im
Allgemeinen betrifft die vorliegende Offenbarung die Problematik
der Handhabung einer Anforderung für native Methoden, die in einer
ersten plattformunabhängigen
virtuellen Maschine auszuführen
sind, indem eine native Codierung oder Bibliothek in die Anwendungsdatei
eingebettet werden, die für
die virtuelle Maschine während
der Laufzeit „nicht
sichtbar” sind,
d. h. die nach dem Übersetzen der
Anwendungsdateien nicht sichtbar sind, die aber während der
Vorbereitung der Anwendungsdateien für das Ausführen in der virtuellen Maschine
verwendet werden. Zu diesem Zweck werden die plattformunabhängigen Befehle
der Anwendungsdatei nach einer Referenz zu einer nativen Methode
durchsucht, beispielsweise beim Verifizieren der Konsistenz und anderer
Eigenschaften der Anwendungsdatei. Wenn eine entsprechende Referenz
erkannt wird, wird nach einer eingebetteten nativen Codierung gesucht, die
von der virtuellen Maschine vor der eigentlichen Laufzeit der betrachteten
Anwendungsdatei lesbar ist. Die eingebettete native Codierung kann
mit geeigneten zusätzlichen „Steuerinformationen” verknüpft sein,
um damit eine geeignete Reaktion in Bezug auf eine Anforderung für eine native
Methode zu ermöglichen.
Beispielsweise wird die eingebettete Codierung und/oder die zusätzliche
Information nach einer geeigneten Implementierung der angeforderten nativen
Methode durchsucht und kann, wenn eine geeignete Implementierung
erkannt wird, in einen geeigneten Speicher kopiert werden, so dass
dieser somit für
die virtuelle Maschine während
er Laufzeit der Anwendungsdatei verfügbar ist. Somit kann die entsprechende
Kopie des nativen Codesegment für
jede weitere Bibliotheksverknüpfung
verwendet werden, wodurch durch einen Anwender zu initiierende plattformspezifische
Operationen vermieden werden, die die Verfügbarkeit der nativen Codierungsbibliothek während der
Laufzeit der Anwendungsdatei sicherstellen sollen. Auf diese Weise
können
plattformspezifische Merkmale in die plattformunabhängige Anwendung
eingebunden werden, wodurch die Sourcen erweitert und somit das
Leistungsverhalten der plattformunabhängigen Anwendungen verbessert wird,
ohne dass eine spezielle Kenntnis über das betrachtete Hardwaresystem
erforderlich ist. Somit kann die Eigenschaft der Plattformabhängigkeit
zu einem gewissen Grade erweitert werden, indem der Einbau nativer
Methoden vereinfacht wird. Es sollte beachtet werden, dass die Systeme
und Mechanismen, wie sie hierin beschrieben sind, sehr vorteilhaft in
Verbindung mit einer virtuellen JAVA-Maschine angewendet werden
können,
da hier effizient Werkzeuge zum Implementieren des Mechanismus verfügbar sind,
da beispielsweise die Klassendateistruktur für eine virtuelle JAVA-Maschine
den Einbau zusätzlicher
Abschnitte ermöglicht,
die von der virtuellen Maschine während der Laufzeit ignoriert
werden, solange die standardmäßigen Klassenabschnitte
Erfordernisse im Hinblick auf Sicherheit, Konsistenz und dergleichen
genügen.
Des weiteren kann JAVA ein Teil der virtuellen Maschine, der für das „Vorbereiten” der Klassendateien
für das
Ausführen
durch die virtuelle Maschine verantwortlich ist, in einfacher Weise
modifiziert werden, so dass Zugriff zu zusätzlichen Informationen, die
in der Klassendatei vorgesehen ist, möglich ist, wobei diese Informationen
dann in geeigneter Weise verwendet werden können, um native Codierungen
oder Bibliotheken während
der Laufzeit der betrachteten Klassendatei bereitzustellen. Jedoch
können
die hierin beschriebenen Mechanismen auch andere Implementierungen
virtueller Maschinen angewendet werden, indem die jeweiligen Anwendungsparteien
in geeigneter Weise konfiguriert werden, so dass diese die erforderlichen
nativen Codierungssegmente enthalten, und indem die nativen Codierungselemente
so gehandhabt werden, dass Zugriff während der Laufzeit der betrachteten
Anwendungsdatei sichergestellt ist. Folglich sollte die vorliegende
Offenbarung nicht auf eine spezielle Implementierung einer virtuellen
Maschine eingeschränkt erachtet
werden, sofern derartige Einschränkungen nicht
explizit in den angefügten
Patentansprüchen und/oder
in den in der Beschreibung dargelegten Ausführungsformen benannt sind.
-
Mit
Bezug zu den 1a bis 1d werden nunmehr
weitere anschauliche Ausführungsformen detaillierter
beschrieben.
-
1a zeigt
schematisch ein elektronisches Gerät 150, das ein Computersystem
einer beliebigen Art, etwa einen tragbaren Computer, beispielsweise in
Form eines kleinen PDA (persönlicher
digitaler Assistent), eines Laptops und dergleichen, ein stationäres Computersystem
und dergleichen repräsentiert. In
anderen Fällen
repräsentiert
das elektronische Gerät 150 eine
beliebige Einrichtung, etwa ein Mobiltelefon, eine elektronische
Schaltung mit Sensorelementen und dergleichen, dass geeignete Rechenressourcen
zum Einrichten einer virtuellen Maschine aufweist. Das elektronische
Gerät 150 umfasst
eine Plattform 150, die als eine Gerätekonfiguration zu verstehen
ist, die für
das Einrichten einer virtuellen Maschine erforderlichen Ressourcen
bereitstellt, wobei die Gerätekonfiguration
in Kombination mit einem speziellen Betriebssystem betrieben werden
kann, wie es typischerweise in Computersystemen verwendet wird.
Somit umfasst die Plattform 100 zumindest eine zentrale
Recheneinheit 101, etwa eine beliebige Art eines Mikroprozessors,
einer Mikrosteuerung und dergleichen, in welcher elektronische Schaltungen die
erforderlichen Hardwarekomponenten, etwa einen CPU-Kern, Pufferspeicher,
interner Signalbusse, Versorgungsspannungen und dergleichen bereitstellen.
Es sollte beachtet werden, dass die CPU 101 nicht notwendigerweise
als eine Einzelchipkomponente vorgesehen ist, sondern dass diese
mehrere individuelle Halbleiterchips aufweisen kann, um damit die
gewünschte
Funktionsweise in Abhängigkeit von
der gesamten Komplexität
der gesamten Plattform 100 bereitzustellen. In ähnlicher
Weise ist ein Speicher 102 vorgesehen und besitzt einen
beliebigen geeigneten Aufbau, wobei der Speicher 102 beispielsweise
nicht-flüchtige
Speicher, etwa eine Festplatte, einen Flash-Speicher und dergleichen und/oder
flüchtige
Speicher und Richtungen in Form von RAM-(Speicher mit wahlfreiem
Zugriff)Bauelementen und dergleichen aufweisen kann. Des weiteren
sind die CPU 101 und der Speicher 102 durch ein Bussystem 103 verbunden,
so dass ein Datenaustausch zwischen der CPU und dem Speicher 102 möglich ist.
Es sollte beachtet werden, dass weitere Komponenten, etwa Spannungsquellen,
I/O-Komponenten und dergleichen gemäß der Konfiguration der Plattform 100 vorgesehen
sind, wobei diese Komponente nicht gezeigt sind. In der gezeigten
Ausführungsform
umfasst die Plattform 100 ein Betriebssystem (OS) 104,
das als ein geeigneter Befehlssatz zu verstehen ist, der in der
CPU 101 während
des Betriebs des Geräts 150 ausgeführt wird,
wodurch eine Schnittstelle zwischen plattformspezifischen Anwendungen
und der CPU 101 erzeugt wird. D. h., das Betriebssystem 104 koordiniert
die Abarbeitung einer oder mehrerer plattformspezifischer Anwendungen und
stellt ferner die Vielzahl definierter Anwendungen bereit, die als
Bibliotheken 104a bezeichnet werden und die für entsprechende
plattformspezifische Anwendungen verfügbar sind, um damit das gesamte Leistungsverhalten
zu verbessern. Es sollte beachtet werden, dass eine Anwendung, die
direkt dem Betriebssystem 104 zugeleitet wird, im Weiteren
als plattformspezifische Anwendung bezeichnet wird, da diese Art
der Anwendung entwickelt werden muss, indem zumindest spezielle
Merkmale des Betriebssystems 104 berücksichtigt werden, während auch
in vielen Fällen
gerätespezifische
Eigenheiten der CPU 101, des Speichers 102 und/oder
des Bussystems 103 Berücksichtigung
finden müssen.
-
Des
weiteren umfasst das elektronische Gerät 150 eine virtuelle
Maschine, die als eine plattformabhängige Anwendung für die Plattform 100 zu
verstehen ist, d. h. die virtuelle Maschine 110 repräsentiert
eine Vielzahl plattformspezifischer Befehle, die, wenn sie von der
Plattform 100 ausgeführt
werden, eine Plattform simulieren, die gut definierte standardmäßige Eigenschaften
im Hinblick auf eine Anwendung bereitstellt, die von der virtuellen
Maschine 110 ausgeführt
wird. Somit repräsentiert,
wie zuvor erläutert
ist, die virtuelle Maschine 110 in Bezug auf die Plattform 100 eine
plattformspezifische Anwendung, die wiederum eine standardmäßige Betriebsumgebung
für eine
beliebige Anwendung repräsentiert,
die auf die virtuelle Maschine 110 zugeschnitten ist. In diesem
Sinne wird eine Anwendung für
die virtuelle Maschine 110, unabhängig vom Aufbau der Plattform 100,
als eine plattformunabhängige
Anwendung bezeichnet. In der gezeigten Ausführungsform umfasst die virtuelle
Maschine eine Bytecodeausführungseinheit 111 und
eine Ladeeinheit 112, die als Klassenlader bezeichnet werden
kann, wenn die virtuelle Maschine eine virtuelle JAVA-Maschine (JVM)
bezeichnet. In dem in 1a gezeigten Zustand umfasst
das elektrische Gerät 150 eine
oder mehrere Quellen für Anwendungsdateien,
etwa eine Datenbank 113, die mit der die virtuelle Maschine 110 repräsentierenden Anwendung
verbunden ist, Anwendungen, die von einem entfernten Computersystem
bereitgestellt werden oder einem anderen Dateiverteiler, beispielsweise über ein
geeignetes Netzwerk, das Internet, wie dies durch 114 angegeben
ist, mit anwendungsspezifischen Dateien 115, die lokal
in der Plattform 100 gespeichert sind, und dergleichen.
Mindestens eine der Dateiquellen 113, 114 und 115 enthält eine
Anwendungsdatei 120, die eine Anforderung für native
Codierung aufweist, um damit Nutzen aus plattformspezifischen Bibliotheken
zu ziehen, etwa den Bibliotheken 104a. Somit trägt in konventionellen
virtuellen Maschinen eine entspre chende Anwendungsdatei zu einem
gewissen Grad an Plattformabhängigkeit
bei, da entsprechende Methoden erforderlich sind, um die Verfügbarkeit
zugehöriger
nativer Coderessourcen während
der Laufzeit der Anwendungsdatei in der virtuellen Maschine 110 sicherzustellen.
Gemäß den hierin
offenbarten Prinzipien enthält
die Anwendungsdatei 120, die auch als Klassendatei bezeichnet
werden kann, wenn die virtuelle Maschine eine JAVA-Umgebung repräsentiert,
eine native Codierung 125 zusätzlich zu den plattformunabhängigen Befehlen,
die von der Bytecodierungsausführungseinheit 111 verarbeitet
werden. Der native Code oder die Bibliothek 125 repräsentiert
eine Befehlsgruppe, die zum Ausführen
einer tiefen Methode geeignet ist, die somit direkt von der Plattform 100 auf
der Grundlage eines geeigneten Schnittstellensystems (nicht gezeigt)
bearbeitet werden kann, wodurch ein besseres Leistungsverhalten
einer Anwendung oder eines Teils davon, der der Datei 120 entspricht,
erreicht wird. Zu diesem Zweck wird der native Code 125 so eingebettet,
dass die Funktionsweise der Einheit 111 durch das Vorhandensein
des nativen Codes 125 nicht beeinflusst wird, so dass die
entsprechenden plattformunabhängigen
Befehle 121 ohne Steuerung abgearbeitet werden. Andererseits
kann der native Code 125 effizient beim „Vorbereiten” der Anwendungsdatei 120 durch
die Einheit 112 verwendet werden, um einen Zugriff auf
den nativen Code oder eine Kopie davon während der eigentlichen Laufzeit
der Anwendungsdatei 120 zu ermöglichen.
-
Während des
Betriebs des elektronischen Geräts 150 wird
zum Ausführen
einer Anwendung angefordert, die die Anwendungsdatei 120 enthält, wodurch
die Aktivierung der virtuellen Maschine 110 initiiert wird,
wenn dies aktuell nicht in Betrieb ist. Die Einheit 112,
etwa ein JAVA-Klassenlader, der bearbeitet im Grunde eine Anforderung
für eine
Anwendungsdatei, etwa eine Klassendatei, die von der Einheit 111 ausgegeben
wird. Das Abarbeiten einer entsprechenden Anforderung für eine Anwendungsdatei kann
das Suchen nach einer entsprechenden Anwendungsdatei beinhalten,
beispielsweise können die
diversen Quellen 113, 114 und 115 durchsucht werden,
und die Verifizierung spezieller Merkmale von Klassendateien kann
ebenfalls enthalten sein, etwa die Konsistenz zu sprachenspezifischen
Formaterfordernissen, Sicherheitsaspekten und dergleichen. Die Anwendungsdatei
wird dann aufgelöst,
d. h. die Datei wird vollständig
für das
Ausführen
vorbereitet. Die Aktivität
der Einheit 112 kann Operationen beinhalten, etwa das Konvertieren
der plattformunabhängigen
Befehlsgruppe, die in den Daten 112 enthalten ist, in ein
Laufzeitformat, das von der Einheit 111 verwendet wird.
Des weiteren erkennt die Einheit 112 Anforderungen für eine native
Methode in den plattformunabhängigen
Befehlen und kann beim Erkennen nach einer geeigneten Implementierung
der native Methode innerhalb des nativen Codesegments 125 suchen.
Wenn eine geeignete Implementierung in dem Segment 125 erkannt
wird, wird die Vorbereitung der Anwendungsdatei 120 fortgesetzt, indem
der Zugriff auf die geeignete Implementierung sichergestellt wird,
beispielsweise, indem zumindest ein Teil des Segments 125 in
einem zugeordneten Speicherbereich kopiert und der entsprechende Speicherbereich
für weitere
Bibliothektsverknüpfungsoperationen
verwendet wird, die in der Anwendungsdatei 120 erforderlich
sind.
-
1b zeigt
schematisch eine Ansicht der Anwendungsdatei 120 gemäß einer
anschaulichen Ausführungsform.
Wie gezeigt, repräsentiert
die Anwendungsdatei 120 eine Klassendatei einer JAVA-Umgebung,
wobei der „standardmäßige” JAVA-Informationsinhalt 121 in
einem speziellen Format vorgesehen ist, das durch die Sprachspezifikationen
für JAVA
festgelegt ist, wie sie im Stand der Technik bekannt sind. Beispielsweise
müssen
mehrere Abschnitte, die hier in vereinfachter Weise magische Zahl,
Version, Konstantensammlung, Zugriff, Klasse, Schnittstelle, Felder,
Methode und Attribute genannt sind, so dass mit der JAVA-Sprache
konsistent ist. Beim Einladen der Anwendungsdatei 120 wird
folglich die Konsistenz der Abschnitte der Inhalte 121 verifiziert,
wobei während
dieser Phase zusätzliche
Abschnitte, die als „lib1”, „lib2”, ..., „lib-Information” bezeichnet
sind, im Hinblick auf die Konsistenz der entsprechenden Sprachenspezifikationen
ignoriert werden. Die zusätzlichen
Abschnitte, die auch als Abschnitte 125a, ..., 125n bezeichnet
werden, sind während
der Konsistenzprüfung
der Abschnitte des Bereichs 121 „unsichtbar”, indem
etwa ein geeigneter Kopfbereich des Abschnitts vorgesehen wird, der
nicht mit den Sprachspezifierungen in Konflikt ist und der die Abschnitt 125a,
..., 125n als nicht standardmäßige Abschnitte kennzeichnet.
Es sollte beachtet werden, dass eine der Abschnitte 125n eine beliebige
zusätzliche
Information aufweisen kann, um in geeigneter Weise die tiefen Codesegmente
zu bilden, während
in anderen Fällen
jeder der Abschnitte 125a, ..., 125n die entsprechende „Steuerungsinformation” enthält, um beispielsweise
entsprechende native Methoden zu kennzeichnen, für die eine Implementierung
vorgesehen ist, für
die entsprechende Implementierungen relevant sind. Somit werden
entsprechende Anwendungdatein den gewissen Grad an Plattformunabhängigkeit
bereitgestellt, indem mehrere plattformspezifische Eigenschaften
für unterschiedlichen
Arten an Plattformen eingebaut werden, wodurch das Leistungsvermögen und
die Anwenderfreundlichkeit der entsprechenden Anwendungen deutlich
erhöht
wird. In anderen Fällen
wird das Leistungsvermögen
mit einer grundlegenden gewissen Anwendung verbessert, indem plattformspezifische
Eigenschaften integriert wer den, wobei grundsätzlich die gleiche Anwendung
der unterschiedlichen Plattformen zugeordnet werden kann, indem
unterschiedliche plattformspezifische Informationen eingebaut werden.
-
1c zeigt
schematisch einen Aufbau der Einheit 112, die selbst in
Form einer Anwendung implementiert werden kann, die durch eine virtuelle
Maschine 110 ausführbar
ist. Wie beispielsweise zuvor erläutert ist, repräsentiert
die JAVA eine objektorientierte Sprache, in der gewisse Eigenschaften
grundlegender Klassen oder die Elternklassen an die Kindklassen
weiter verwendet werden, wobei einige dieser Eigenschaften, d. h.,
Methoden, beschrieben werden können,
so dass diverse Fähigkeiten
der Elternklasse erweitert werden. Beispielsweise repräsentiert
ein standardmäßiger Klassenlader
der JAVA-Umgebung die Elternklasse und ein modifizierter Klassenlader
kann definiert werden, indem die Fähigkeit der Handhabung des
nativen Codesegments 125 der Anwendungsdatei 120 (siehe 1b)
eingerichtet wird, um damit in geeigneter Weise die Anforderung
für native
Methoden abzuarbeiten. In der in 1c gezeigten
Ausführungsform
umfasst die Ladeeinheit 112 mehrere Methoden, die von dem
Elternklassenlader geerbt werden und nicht geändert werden, da diese Methoden
als „Final” bezeichnet sind,
wie dies durch das Bezugszeichen 114 angegeben ist. Andererseits
ist die Methode „Ladeklasse” des Elternklassenladers
erweitert, so dass die Handhabung des nativen Codesegments mit eingeschlossen
ist, wodurch ein entsprechende Methode 112 erhalten wird.
-
1d zeigt
schematisch einen anschaulichen Mechanismus zum Einrichten der erforderlichen
Funktion zur Handhabung nativer Codesegmente, wobei dennoch für die Möglichkeit
gesorgt ist, die Konsistenz des standardmäßigen Informationsinhaltes
zu prüfen,
etwa des Bereichs 121 (siehe 1e).
Wie gezeigt, umfasst die Methode „Ladeklasse” 113 einen
ersten Schritt 113a, um eine Anforderung für eine native
Methode in dem entsprechenden plattformunabhängigen Befehl 121 der
Klassendatei 120 zu erkennen, wie in 1b gezeigt
ist. Wenn eine entsprechende Anforderung für eine native Methode im Schritt 113a nicht
erkannt wird, wird die Methode „Ladeklasse” gemäß einer
vorgegebenen Verhalten weiter, wie dies durch den Schritt 113b angegeben
ist. In diesem Falle wird die Verifizierung der Konsistenz und dergleichen
in der üblichen
Weise ausgeführt.
Wenn eine Anforderung für
eine native Methode im Schritt 113 erkannt wird, geht der
Mechanismus zum Schritt 113c weiter, in welchem nach einem
eingebetteten nativen Code in der Anwendungsdatei gesucht wird.
Zu diesem Zweck ist die Methode „Ladeklasse” geeigneter
Weise so gestal tet, dass entsprechende zusätzliche Abschnitte oder Information,
die in den zusätzlichen
Abschnitten 125a, ..., 125n (siehe 1b)
vorgesehen ist, erkannt wird, so dass das Vorhandensein des eingebetteten
nativen Codes erkannt wird und auch weitere Informationen im Hinblick
auf die Anforderung für
eine native Methode bewertet wird. Auf der Grundlage der zusätzlichen
Information, die in dem Abschnitten 125a, ..., 125n der 1b enthalten
ist, kann beispielsweise bewertet werden, ob eine geeignete Implementierung
für die
anforderte native Methode verfügbar
ist. Wenn der entsprechende eingebettete native Code erkannt wird
oder eine geeignete Implementierung nicht verfügbar ist innerhalb der eingebetteten
nativen Codierung, geht der Mechanismus zum Schritt 113d weiter
und wendet dann das voreingestellte Verhalten an. Im anderen Falle,
wenn also eine geeignete Implementierung erkannt wird, die für die aktuelle
Plattformarchitektur geeignet ist, wird das zugehörige native
Codesegment oder ein Teil davon, etwa eine spezielle DLL oder eine
gemeinsame Bibliothek, in einen zugeordneten Speicherbereich kopiert
und kann für
weitere Bibliotheksverknüpfungsoperationen
der betrachten Klassendatei verwendet werden. Es werden weitere
erforderliche Methoden von dem Klassenlader 121 eingeladen,
wobei die betrachtete Klassendatei dann für die Ausführung durch die Einheit 111 (siehe 1a)
vorbereitet wird, beispielsweise indem die Methoden 114 aus 1c angewendet
werden. Während
der verbleibenden Verarbeitung des Klassenladers 112 bleibt
somit das eingebettete native Segment 125 (siehe 1c)
unsichtbar und stört
somit das Ausführen
der Befehle in dem Bereich 121 nicht (siehe 1d).
-
Es
gilt also: Die vorliegende Offenbarung stellt elektronische Geräte bereit,
die auf der Grundlage einer virtuellen Maschine und Anwendungsdateien
betrieben werden können,
die ein eingebettetes natives Codierungssegment besitzen, um damit
die Möglichkeit
bieten, plattformspezifische Eigenschaften effizient zu nutzen,
ohne dass die Einwirkung des Nutzers erforderlich ist. Die speziellen
Anwendungsdateien können
durch eine beliebige Quelle, etwa durch ein entferntes Computersystem über ein
geeignetes Netzwerk, oder durch ein anderes geeignetes Speichermedium,
auf das von der Zielplattform zugegriffen werden kann, bereitgestellt
werden. Des weiteren besitzt die virtuelle Maschine darin eingebettet einen
geeigneten Mechanismus zum Erkenn einer Anforderung für native
Methoden, in welchem Falle die entsprechende Anwendungdatei nach
eingebetteten nativen Codesegmenten durchsucht wird, die dann für den Einbau
von Bibliotheken, wie sie durch die Anwendungsdatei erforderlich
sind, verwendet werden. Beispielsweise wird ein modifizierter Klassenlader
bereitgestellt, etwa auf der Grundlage eines computerlesbaren Speichermedi ums,
und wird in den virtuellen Maschinenmechanismus eingebaut, um damit
die erweiterte Funktionsfähigkeit
zu ermöglichen.
Folglich kann die Verbreitung von JAVA-Anwendungen, die native Methoden
erfordern, deutlich vereinfacht werden. Bessere Versionen nativer
Methoden für
spezielle Plattformen, möglicherweise
in Verbindung mit allgemeineren Implementierungen, können in
einer sehr effizienten Weise gepackt werden, die dann effizient
von der virtuelle Maschine, beispielsweise dem Klassenlader „aufgelöst” werden,
etwa durch geeignete Techniken, etwa Mustervergleichsmechanismen
und dergleichen, um eine optimale Implementierung während der
Laufzeit auszuwählen.
Ferner können
mehrere Versionen einer oder mehrerer Klassen in die virtuelle Maschine gleichzeitig
eingeladen werden, selbst wenn unterschiedliche native Methoden
von den diversen Versionen angefordert werden, da ein Konflikt in
Bezug auf Bibliotheken durch die zuvor beschriebenen Mechanismen
effizient vermieden werden kann.
-
Weitere
Modifizierungen und Variationen der vorliegenden Offenbarung werden
für den
Fachmann angesichts dieser Beschreibung offenkundig. Daher dient
diese Beschreibung lediglich anschaulichen Zwecken und ist dazu
gedacht, dem Fachmann die allgemeine Art und Weise des Ausführens der
hierin offenbarten Prinzipien zu vermitteln. Selbstverständlich sind
die hierin gezeigten und beschriebenen Formen als die gegenwärtig bevorzugten
Ausführungsformen
zu betrachten.