-
BEREICH DER ERFINDUNG
-
Die vorliegende Erfindung betrifft
das dynamische Herunterladen von Code und die Verknüpfung (linking)
in Java-Laufzeitumgebungen
mit Ressourcen-Engpass (resource constraint Java runtime environments) wie
zum Beispiel JavaCards.
-
STAND DER TECHNIK
-
In einem herkömmlichen Java-System werden
Verweise auf Klassenstrukturen (interne und externe) mittels einer
indirekten Namenssuche über
einen sogenannten Konstantenpool aufgelöst. Eine solche Vorgehensweise
kann nur in einem System angewendet werden, das genügend Ressourcen
im Sinne von Verarbeitungsleistung und internen Ressourcen bereitstellt.
-
In einem Laufzeitsystem mit Ressourcen-Engpass
(z. B. JavaCard) ist diese Vorgehensweise nicht vielversprechend.
Stattdessen könnte
man aufgelöste
Verweise auf Klassenstrukturen verwenden, so dass Verweisoperatoren überflüssig werden
und die Pflege des Konstantenpools vermieden werden kann.
-
Das Auflösen der Verweise (Verknüpfung) ist
der Gegenstand der vorliegenden Erfindung.
-
Es ist eine Aufgabe der vorliegenden
Erfindung, in Java-Laufzeitumgebungen
mit Ressourcen-Engpass eine wirksame Verknüpfung zu erzielen.
-
Es ist eine Aufgabe der vorliegenden
Erfindung, eine platzsparende und laufzeiteffiziente Verknüpfung in
Java-Lauffzeitumgebungen
mit Ressourcen-Engpass zu erzielen, während gleichzeitig ein spätes Binden des
Codes ermöglicht
wird.
-
Diese Aufgaben werden von einem Java-Laufzeitsystem
nach Anspruch 1 und einem Verfahren nach Anspruch 3 gelöst.
-
Bevorzugte Ausführungsformen sind in den. abhängigen Ansprüchen dargelegt.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
1 zeigt
die Verknüpfung
mit dem von JavaSoft vorgeschlagenen CAP-Dateiformat.
-
2 zeigt
die Verknüpfung
durch Offset mit dem hier vorgeschlagenen Dateiformat.
-
3 zeigt
die Verknüpfung
durch Name mit dem hier vorgeschlagenen Dateiformat.
-
AUSFÜHRLICHE
BESCHREIBUNG
-
Im Folgenden wird ein allgemeiner Überblick über die
vorliegende Erfindung gegeben, und es werden Aspekte der Ausführung angesprochen.
Java ist eine Programmiersprache und -umgebung, die von Sun Microsystems,
Inc., 2550 Garcia Ave., Mountain View, CA 94043-1100, USA, entwickelt
wurde; der Begriff "Java" ist ein Warenzeichen dieses Unternehmens.
-
Da sich die vorliegende Beschreibung
auch mit Einzelheiten der Ausführung
befasst, wird davon ausgegangen, dass der Fachmann mit den gründlegenden
Mechanismen der "Java Virtual Machine" (JVM) und ihrer Ausführung vertraut
ist. Die Programmiersprache Java und die Ausführung der JVM wurden von J.
Goslin, B. Joy und G. Tele in "The Java Language Specification"
und von T. Lindholm und F. Yellin in "The Java Virtual machine Specification",
beide erschienen bei Addison-Wesley
Publishing Co., 1996, umfassend beschrieben. Es sei jedoch angemerkt,
dass sich die virtuelle Java-Card-Maschine, die hier als Java-Cord
VM bezeichnet wird, in mehreren Aspekten unterscheidet, da nur eine
Teilmenge des Bytecodes sowie zusätzliche Bytecodes verwendet
werden.
-
1.0 Von JavaSoft vorgeschlagenes
CAP-Dateiformat
-
Das CAP-Dateiformat, wie es von JavaSoft
vorgeschlagen wurde, teilt eine CAP-Datei in mehrere Teile auf.
Eine CAP-Datei enthält
hauptsächlich
einen Text- und einen Datenteil. Der Textteil enthält die Klassenstrukturen,
die Methodenstrukturen und die Bytecode-Befehle. Der Datenteil enthält die statischen
Felder des Cardlet.
-
Der Textteil referenziert alle Symbole
(Klassen, Methoden usw.), deren tatsächliche Adressen vor dem Verknüpfungszeitpunkt
nicht bekannt sind, mittels eines Offset in den Konstantenpool.
Für jedes
dieser Symbole enthält
der Konstantenpool die AID für
das Zielpaket und den Offset dieses Symbols in, diesem Zielpaket (d.
h. dem Paket, mit dem eine Verknüpfung
stattfindet). Der Konstantenpool stellt diese Offsets für alle importierten
Symbole (die Symbole, die in anderen Paketen angegeben sind) und
für alle
exportierten Symbole (die Symbole, die in dem Cardlet, das geladen
wird, angegeben sind und auf die darin zugegriffen wird) bereit.
-
Der Aufbau des Textteils, des Datenteils
und des Konstantenpools stellt genügend Informationen zur Ausführung eines
Cardlet bereit. Nachdem ein Cardlet geladen wurde, könnte das
Verknüpfungsprogramm (Linker)
den Konstantenpool schrittweise durchlaufen und die Offsets der
Symbole in ihre Zielpakete durch ihre realen Adressen ersetzen.
Das Verrknüpfungsprogramm
muss lediglich das bestimmte Paket mittels der gegebenen AID suchen,
seine Anfangsadresse zum Symbol-Offset hinzufügen und diese Information in
den Konstantenpool zurückspeichern.
Die Java-Card VM kann dann diese Adressen im Konstantenpool für die Interpretation
nutzen. Der Konstantenpool selbst wird zur Laufzeit jedoch nicht
benötigt.
Tatsächlich
würde er
einen weiteren überflüssigen Verweisoperator
erforderlich machen, um die Adresse eines Symbols während der
Interpretation zu finden. Außerdem
nimmt der Konstantenpool unnötigerweise
Platz auf der Karte in Anspruch. Das JavaSoft-CAP-Dateiformat verwendet
daher Berichtigungstabellen (fixup tables) für die einzelnen Teile, damit
der Konstantenpool nach dem Verknüpfungsvorgang nicht mehr notwendig
ist. Die Berichtigungstabelle enthält alle Positionen in dem Textteil,
an denen eine Verschiebung (relocation) stattfinden muss. Das Verknüpfungsprogramm
durchläuft
die Berichtigungstabelle und übernimmt
den Offset an dieser Position in den Konstantenpool. Dann löst es die
Adresse dieses Symbols auf und speichert sie an der ursprünglichen
Position im Textteil. Der Übersetzer
(Interpreter) kann diese Adressen dann zur Laufzeit direkt verwenden,
und der Konstantenpool kann daher nach dem Verknüpfungsprozess entfernt werden.
Die einzigen Teile, die nach dem Verknüpfungsprozess auf der Karte
verbleiben, sind der Text- und der Datenteil.
-
Das Verknüpfen von Cardlets mit vorher
berechneten und fest codierten Offsets in Zielpakete lässt ein kompaktes
System zu. Jedoch bietet es nicht genügend Flexibilität, um verschiedene
Ausführungen
von Systemklassen und festgelegte Erweiterungen auf verschiedenen
Karten zu ermöglichen.
Beispielsweise ist es unwahrscheinlich, dass ein Cardlet, das gegen
die Systemklassen von IBM und eine Erweiterung von JavaSoft getauscht
wurde, auf einer Karte läuft,
bei der das System-Cardlet
von JavaSoft und das Erweiterung-Cardlet von IBM stammen. Der Hauptgrund
hierfür
besteht darin, dass die Offsets von einzelnen Klassen und Methoden
und die Feld-Offsets
von Instanzen von Ausführungen
zu Ausführung
unterschiedlich sind.
-
Die folgende Erfindung fußt auf den
Gedanken des aktuellen Vorschlags von JavaSoft, wobei es diesen
durch einen zuätzlichen
einfachen und flexiblen symbolischen Verknüpfungsmechanismus verbessert.
-
2.0 Erfindungsgemäßes CAP-Dateiformat
-
Das CAP-Dateiformat gemäß der vorliegenden
Erfindung teilt die CAP-Datei ebenfalls in verschiedene Teile auf.
Der Textteil enthält
die Klassenstrukturen, die Methodenstrukturen und die Bytecode-Befehle,
der Datenteil wieder die statischen Felder. Die CAP-Datei legt die
notwendigen Verschiebeinformationen ebenfalls in Berichtigungstabellen
ab. Es gibt eine Berichtigungstabelle für jedes Paket, mit dem das
Cardlet verknüpft wird
(d. h. das Zielpaket).
-
Die Berichtigungstabelle enthält ebenfalls
die Position im Texa- oder Datenteil, an der eine Verschiebung stattfinden
muss. Im einfachen Fall werden diese Stellen ebenfalls um einen
vorher berechneten Offset in vertrauenswürdige und bekannte Zielpakete
verschoben. In diesem Fall sucht das Verknüpfungsprogramm die Anfangsadresse
des Pakets mit der gegebenen Ziel-AID (Target AID), fügt den Offset
in das Zielpaket hinzu und speichert diesen Wert an der ursprünglichen
Position im Textteil. Der Offset in das Zielpaket kann entweder in
der Berichtigungstabelle oder im Textteil an der Verschiebeadresse
abgelegt werden, um die Berichtigungstabelle kleiner zu halten.
Die Verschiebung um einen Offset kann für die meisten Verweise innerhalb
des geladenen Cardlet selbst immer angewendet werden. Dem Umsetzer
(Converter) ist die vorherige Berechnung dieser Offsets gestattet,
ohne jedoch die Kompatibilität
zu beeinträchtigen.
-
Aus Gründen der Systemintegrität sollten
Verweise auf andere externe Pakete nicht mittels vorher berechneter
Offsets verknüpft
werden. Stattdessen sollte während
des Verknüpfungsprozesses
ein Name oder Bezeichner für
Verweise auf andere Pakete verwendet werden. Diese Namen und ihre
zugehörigen
Werte müssen
auf der Karte nur für
Pakete gespeichert werden, die von mehreren Applets gemeinsam benutzt
werden. Da diese Tabellen von Name/Wert-Paaren so klein wie möglich sein
sollten, schränkt
dieses CAP-Dateiformat die Namensgebung von Elementen von Klassendateien
zwar ein, ermöglicht
aber immer noch eine herstellerspezifische Umsetzung von unterschiedlichen
Spezifikationen:
-
- – öffentliche
Klassen: müssen
benannt sein und exportiert werden können.
- – öffentliche
statische Methoden und Konstruktoren: ebenso
- – öffentliche
statische Felder: ebenso
- – virtuelle
Methoden:
Der Übersetzer
findet eine virtuelles Methode über
einen Index in die virtuelle Methodentabelle. Diese Indexe und die
virtuelle Methodentabelle müssten
auf der Karte aufgelöst
werden, wenn die JavaCard-Umgebung das späte Binden des Codes von virtuellen
Methoden, das bei Java Standard ist, unterstützen wollte. Während der Erstellung
der Methodentabelle muss das Verknüpfungsprogramm entscheiden,
ob eine Methode eine andere Methode in der Methodentabelle erbt.
Da diese Methoden in verschiedenen Cardlets festgelegt werden könnten, muss
ein globales Namensgebungsschema für Methoden eingeführt werden,
um zu entscheiden, ob zwei Methoden denselben Typ haben. Da das
späte Binden
des Codes von virtuellen Methodenaufrufen ein globales Namensgebungsschema
und zusätzliche
Ressourcen auf der Karte erforderlich macht, um virtuelle Methoden
aufzulösen
und zu benennen, wird es von dem erfindungsgemäßen CAP-Dateiformat nicht unterstützt. Aber
selbst mit dieser Einschränkung
bleibt genügend
Platz für
herstellerspezifische Ausführungen
von Kernpaketen und Erweiterungen. Der Programmierer kann private
oder statische Methoden und Klassen uneingeschränkt hinzufügen. Er kann auch nichtprivate
Instanzmethoden hinzufügen,
wenn sie nicht geerbt und als endgültig deklariert werden. Der
Umsetzer kann dann Aufrufe dieser Methoden durch Direktaufrufe ersetzen.
- – Instanzfelder:
Die
Anzahl und die Arten von Instazfeldern in einer Klasse werden gewöhnlich nicht
mittels Spezifikation festgelegt, und so gibt es bei den Ausführungen
verschiedener Hersteller Abweichungen. Daher muss der Vorschlag
für das
CAP-Dateiformat das Binden von Feld-Offsets ansprechen. Die Verwendung von
Feldern in Bezug auf den Verknüpfungsprozess
kann in die folgenden drei Kategorien gegliedert werden:
- – vorher
berechnete Feld-Offsets
Ein Befehl "get-/put-field" referenziert
ein Feld, dessen Klasse und dessen gesamte Superklassen in dem Cardlet
festgelegt werden, in dem es enthalten ist. Der Offset dieses Feldes
kann dann vom Umsetzer vorher berechnet werden und braucht nicht
während
des Ladevorgangs verknüpft
zu werden. Wenn es eine Vereinbarung dahingehend gibt, dass die
Objektklasse keine Felddeklarationen enthält, fallen viele Feldzugriffe
in diese Kategorie.
- – Zugriff
auf Felder von innerhalb des Cardlet befindlichen Klassen mit einer
oder mehreren beliebigen Superklasse(n), die sich außerhalb
des Cardlet befinden. Dieser Fall muss von einem CAP-Dateiformat
unterstützt werden,
damit Klassen, die in getrennten Paketen festgelegt werden, in Subklassen
unterteilt werden können. Der
Umsetzer kann den Offset des Feldes im Verhältnis zur Instanzgröße der außerhalb
des Cardlet befindlichen Superklasse berechnen und diesen wert in
der CAP-Datei speichern. Während
des Verknüpfungsprozesses
muss der tatsächliche
Offset des Feldes auf der Grundlage der Größe der Basisklasse erneut berechnet werden.
Dasselbe kann für
das Instanzgrößenelement
der innerhalb des Cardlet befindlichen Klasse durchgeführt werden.
- – Zugriff
auf Felder in außerhalb
des Cardlet befindlichen Superklassen oder in einer beliebigen externen
Klasse.
Instanzfelder werden zwar selten als öffentliche
Felder, häufig
aber als geschützte
Felder deklariert. Der Zugriff auf geschützte Felder könnte durch
die Festlegung von "protected set-/get-field"-Methoden immer gewährt werden,
doch gestattet das vorgeschlagene CAP-Dateiformat auch einen direkten
Zugriff auf solche als geschützt
oder öffentlich
deklarierten Felder. Ein Paket, das ein geschütztes oder öffentliches Instanzfeld exportiert,
muss einen Namen und den Offset für ein solches Feld enthalten,
um eine symbolische Verknüpfung
zu ermöglichen.
-
Ein Paket, das Klassen, Methoden
oder Felder exportiert, enthält
einen Konstantenpool, dessen Einträge die Art (Klasse usw.), den
Namen und den Wert für
dieses Symbol enthalten. Da das CAP-Dateiformat kein globales Namensgebungsschema
zu unterstützen
braucht, können
die Namen für
die zugehörigen
Symbole ohne weiteres festgelegt werden. Die Symbole können von
0 bis n nummeriert und zusammen mit einer Spezifikation der Anwendungsprogrammierschnittstelle
(API) ausgegeben werden. Der Ausführende einer solchen Spezifikation
kann nach wie vor weitere Klassen usw. exportieren, indem er neue
Namen wählt
und dabei bei n + 1 beginnt.
-
3 zeigt
das symbolische Binden eines Applets an ein Zielpaket. Die Einträge in der
Berichtigungstabelle enthalten die Art der Verschiebung (siehe nachstehend),
einen Offset in den Textteil, in den verschoben werden soll, und
den Namen des Symbols (der aus Platzgründen auch an der Position,
die verschoben werden soll, gespeichert werden könnte). Bei dem vorgeschlagenen
Namensgebungsschema kann der Name als Index in den Konstantenpool
des Zielpakets verwendet werden. Die Einträge im Konstantenpool enthalten
die Art des Eintrags, den Namen und den zugehörigen Wert. Das Verknüpfungsprogramm
verschiebt die Einträge
in der Berichtigungstabelle in Abhängigkeit von der Art des Eintrags:
-
- – Eine
Methode muss verschoben werden:
Das Konstantenpool-Element
(constant: pool item) des Zielpakets mit dem gegebenen Namen muss
vom Typ "Methode" sein. Der Wert muss ein Offset in das Zielpaket
sein, in dem die Methode festgelegt ist. Das Verknüpfungsprogramm
berechnet die Adresse der Methode und fixiert den Textteil an dem
bestimmten Offset.
- – Eine
Klasse muss verschoben werden:
wie oben, außer dass das Konstantenpool-Element
mit dem Symbolindex und dem Namen vom Typ "Klasse" sein muss.
- – Ein
statisches Feld muss verschoben werden:
wie oben, außer dass
das Konstantenpool-Element mit dem Symbolindex und dem Namen vom
Typ "statisches Feld" sein muss.
- – Ein
relativer Offset eines Instanzfelds oder ein relativer Wert einer
Klasseninstanzgröße muss
verschoben werden:
Das Konstantenpool-Element des Zielpakets
mit dem gegebenen Namen muss vom Typ "Klasse" sein. Das Verknüpfungsprogramm
berechnet die Adresse der Zielklasse und holt die Klasseninstanzgröße (Letztere
ist ein Element der Klassenstruktur). Das Verknüpfungsprogramm fügt die Instanzgröße zu dem
Wert hinzu, der am Textteil-Offset angegeben ist, und ersetzt Letzteren
durch die Summe.
- – Ein
absoluter Feldzugriff auf eine nicht festgelegte Klasse:
Das
Konstantenpool-Element des Zielpakets mit dem gegebenen Namen muss
vom Typ "Instanzfeld" sein. Der Wert dieses Elements ist der absolute
Offset dieses Felds in eine Instanz seiner Klasse.
-
Wenn das geladene Cardlet ein gemeinsam
benutztes Paket ist und geschützte
oder öffentliche
Felder exportiert, verschiebt das Verknüpfungsprogramm deren Einträge ebenfalls
in den Konstantenpool. Ihre realen Offsets werden in der gleichen
Weise wie relative Offsets von Instanzfeldern verschoben.
-
Die Berichtigungstabellen können entfernt
werden, sobald der Verknüpfungsprozess
abgeschlossen ist. Applets brauchen keinen Konstantenpool, nur Pakete,
die von mehreren Applets gemeinsam benutzt werden können, brauchen
den Konstantenpool zur zukünftigen
Verwendung. Die Größe des Konstantenpools hängt von
der Anzahl der exportierten Elemente und der Größe eines Elements ab. Ein Konstantenpool
für das aktuelle
JavaCard-System
benötigt
derzeit ca. 160 Elemente. Ein Element eines Konstantenpools enthält ein Typ-Feld,
einen Namen und einen Wert, die in 4 Byte gespeichert werden können (bei
dem vorgeschlagenen Namensgebungsschema könnte dies sogar auf drei Byte
verringert werden). Dies ergibt eine Größe eines Konstantenpools von
720 Byte für
alle Systemklassen.
-
Unterschiede zum Vorschlag von JavaSoft:
-
- – Der
JavaSoft-Konstantenpool unterscheidet derzeit nicht zwischen intern
festgelegten und extern festgelegten Elementen. Dies macht es schwierig,
diejenigen Elemente des Konstantenpools zu entfernen, die intern festgelegte
Elemente abdecken.
- – Die
Feld-Offsets in den "get-/put-field"-Befehlen und das Instanzgrößenfeld
in der Klassenstruktur sind nur 8 Bit breit. Daher ist es derzeit
nicht möglich,
diese Werte als Indexe in den Konstantenpool zu verwenden, an denen
Informationen gespeichert werden könnten, um den Offset eines
Feldes während
des Verknüpfungsprozesses
zu binden.
-
Aufgrund dieser beiden Einschränkungen
bedarf der aktuelle Vorschlag von JavaSoft Verbesserungen, damit
ein notwendiges einfaches Namensgebungsschema – wie das hier vorgeschlagene – möglich wird.
-
3.0 Anhang
-
3.1 Kleinere Erweiterungen
-
In manchen Umgebungen gibt es möglicherweise überhaupt
keinen Bedarf an oder keinen Platz für symbolische Informationen
auf der Karte, beispielsweise reicht es unter Umständen aus,
während
des Verknüpfungsprozesses
nur vorher berechnete Offsets zu verwenden. Das CAP-Dateiformat
gemäß der vorliegenden
Erfindung lässt
sich in dieser Richtung auf sichere Weise erweitern:
-
- – Ein
Paket oder Applet enthält
nicht nur eine Versionsnummer, sondern auch die Kennung (ID) des
Herstellers (oder eine Ausführungs-I.D).
- – Die
Einträge
in den Berichtigungstabellen, die auf Elemente des Konstantenpools
verweisen, enthalten auch die Offsets, die der Umsetzer während der
Umsetzzeit berechnen könnte.
- – Zu
Beginn des Herunterladens prüft
der Lader (Loader), ob die von dem Applet benötigten Pakete von demselben
Hersteller stammen (z. B., ob sie genauso ausgeführt sind) wie diejenigen, die
gerade auf der Karte installiert sind. Wenn ja, verwendet der Lader
die Offsets in die Applet-CAP-Datei
während
des Verknüpfungsprozesses.
Andernfalls schlägt
das Herunterladen fehl.
-
3.2 Spezifikationen für referenzierte
Elemente des CAP-Dateiformats
-
Es ist nicht Zweck dieser ausführlichen
Beschreibung, den Inhalt einer CAP-Datei genau anzugeben. Vielmehr
wird darin ausführlich
erörtert,
was sich in der CAP-Datei befinden sollte und befinden muss, wobei mit
dem Vorschlag von JavaSoft begonnen wird. Dennoch geben wir auch
formellere Spezifikationen der in dieser Beschreibung erwähnten Elemente
des CAP-Dateiformats in C-ähnlichen
Deklarationen an. Diese werden hier der Klarheit halber und in nichtoptimierter
Form aufgeführt:
