-
HINTERGRUND
-
Die
vorliegende Erfindung bezieht sich allgemein auf objektorientierte
und bezüglich
der Architektur neutrale Programme für die Verwendung mit ressourcenbeschränkten Einrichtungen
bzw. Geräten,
wie z.B. intelligenten Karten (Smart Cards) und dergleichen.
-
Eine
virtuelle Maschine ist eine abstrakte Rechenmaschine, welche durch
eine Softwareanwendung oder eine Folge von Befehlen erzeugt wurde,
die durch einen Prozessor ausgeführt
werden. Der Begriff "architekturneutral" (hinsichtlich der
Architektur neutral) bezieht sich auf Programme, wie solche, die
in der JavaTM-Programmiersprache geschrieben
wurden, welche durch eine virtuelle Maschine auf einer Vielfalt
von Computerplattformen ausgeführt
werden können,
die eine Vielfalt unterschiedlicher Computerarchitekturen haben.
Beispielsweise verwendet eine virtuelle Maschine, die auf einem
Personal Computer-System auf WindowsTM-Basis
ausgeführt
wird, denselben Satz von Befehlen wie eine virtuelle Maschine, die
auf einem Computersystem auf UNIXTM ausgeführt wird.
Das Ergebnis der plattformunabhängigen
Codierung der Befehlsfolge einer virtuellen Maschine ist ein Strom
von einem oder mehreren Bytecodes, von denen jeder beispielsweise ein
ein Byte langer numerischer Code ist.
-
Die
Verwendung der Programmiersprache Java hat viele Anwendungen gefunden,
einschließlich
beispielsweise solcher, die mit Web-Browsern in Verbindung stehen.
-
Die
Java-Programmiersprache ist objektorientiert. In einem objektorientierten
System beschreibt eine "Klasse" eine Sammlung von
Daten und Methoden, die mit diesen Daten arbeiten. Zusammengenommen
beschreiben die Daten und Methoden den Zustand und das Verhalten
eines Objektes.
-
Die
Java-Programmiersprache ist außerdem
verifizierbar, so daß vor
der Ausführung
einer in der Java-Programmiersprache geschriebenen Anwendung eine
Feststellung getroffen werden kann, ob irgendeine Befehlssequenz
in dem Programm versucht bzw. versuchen würde, Daten eines nicht geeigneten
Typs für
diesen Bytecode zu verarbeiten oder ob die Ausführung von Bytecodebefehlen
in dem Programm einen Unterlauf bzw. Leerlauf oder Überlauf
eines Operandenstapels verursachen wird.
-
Eine
virtuelle JavaTM-Maschine führt virtuellen
Maschinencode aus, der in der Java-Programmiersprache geschrieben ist,
und ist für
die Verwendung mit einer 32-Bit-Architektur ausgelegt. Jedoch haben
viele Einrichtungen bzw. Geräte,
die hinsichtlich ihrer Ressourcen eingeschränkt sind, wie z.B. die Smart
Cards, eine 8-Bit- oder 16-Bit-Architektur. Smart Cards, die auch
als intelligente, tragbare Datenträgerkarten bezeichnet werden,
sind im allgemeinen aus Kunststoff oder Metall hergestellt und haben
einen Elektronikchip, der einen eingebetteten Mikroprozessor enthält, um Programme
auszuführen,
und einen Speicher enthält,
um Programme und Daten zu speichern. Solche Einrichtungen, die in
etwa die Größe einer
Kreditkarte haben können,
haben typischerweise eine relativ begrenzte Speicherkapazität. Beispielsweise
haben einige Smart Cards weniger als 1 Kilobyte (1 K) eines wahlweise
zugreifbaren Speichers (RAM) und auch nur einen relativ begrenzten Nur-Lese-Speicher
(ROM) und/oder nichtflüchtigen
Speicher, wie z.B. einen elektrisch löschbaren, programmierbaren
Nur-Lese-Speicher (EEPROM).
-
Im
allgemeinen stellen Programme, die auf einem Prozessor einer Smart
Card laufen, die von der Card angebotenen Dienste fest. Im Verlaufe
der Zeit müssen
die Programme auf der Card möglicherweise
aktualisiert werden, beispielsweise um eine neue Funktion hinzuzufügen oder
um eine existierende Funktion zu verbessern. Insoweit sollte die
Karte in der Lage sein, neue Programme aufzunehmen, die andere Programme ersetzen
können.
-
Typischerweise
erfordert eine virtuelle Maschine, die Bytecode ausführt (beispielsweise
eine volle virtuelle Java-Maschine), einen meßbaren Betrag an Speicher zum
Laden von Bytecode und zum Auflösen
von Aufrufen. Insbesondere werden in der virtuellen Java-Maschine
symbolische Aufrufe verwendet, um Programmelemente, wie z.B. Klassen,
Methoden und Felder aufzurufen. Ein Aufruf dieser Programmelemente
wird aufgelöst
durch Lokalisieren des Elementes unter Verwendung seines symbolischen
Namens. Derartige Vorgänge
erfordern einen relativ großen
Speicher mit wahlfreiem Zugriff (RAM). In einer Umgebung, in welcher
nur wenig RAM vorhanden ist, ist dies möglicherweise nicht durchführbar. Da
Smart Cards nur wenig kosten dürfen,
beruhen sie auf preiswerten Prozessoren geringer Leistungsfähigkeit
und Speichereinrichtungen geringer Kapazität. Da Aspekte der Kosten und
des Energieverbrauchs erzwingen, daß in derartigen, in ihren Ressourcen
sehr beschränkten
Rechnern Prozessor- und Speicherkomponenten mit geringem Energieverbrauch
und geringer Kapazität
verwendet werden, ist die Fähigkeit,
eine virtuelle Java-Maschine
auf derartigen ressourcenbeschränkten
Einrichtungen zu betreiben, sehr schwierig, aber andererseits auch
wünschenswert.
-
Die
US 5,734,822 offenbart ein
System für
die Vorbearbeitung von Computerprogrammen, bevor sie in Terminals
heruntergeladen werden. Das System umfaßt eine Verpackungseinrichtung,
welche gewisse Information, die in kompilierten, aber noch nicht
verknüpften
Programmen enthalten sind. Die Verpackungseinrichtung löst teilweise
undefinierte Symbole und Neuzuordnungen auf, die auf der Erkenntnis
einer Dispatch-Tabelle in dem Zielterminal beruhen.
-
Die
WO 98/19237 offenbart eine Karte mit integriertem Schaltkreis für die Verwendung
mit einem Terminal. Die Karte mit integrertem Schaltkreis enthält einen
Speicher, der einen Übersetzer
und eine Anwendung speichert. Die Anwendung ist in einer Programmiersprache
hoher Ebene bzw. fortgeschrittenen Programmiersprache, wie z.B.
Java, geschrieben.
-
Der
Teilsatz der Java-Kartensprache 2.0 und die virtuelle Maschinen-Spezifikation
von 1997 beschreibt den Teilsatz der Java-Programmiersprache, der
auf der Java-Kartenplattform verwendet werden kann, wie sie beispielsweise
auf einer Smart Card implementiert ist.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Die
vorliegende Erfindung ist in den anhängenden Ansprüchen definiert.
-
Vorteile
der Erfindung können
einen oder mehrere der folgenden umfassen. Die Erfindung verwendet in
effizienter Weise Ressourcen auf einem hinsichtlich der Ressourcen
begrenzten Gerät
durch Verwenden kleinerer Speicherräume durch eindeutige Tokenkennungen.
Weiterhin kann die Erfindung Aufrufe von exportierten Gegenständen auf
dem ressourcenlimitierten Gerät
verknüpfen
und auflösen.
Durch Metadaten-Dateien, wie z.B. Exportdateien, ermöglicht die
Erfindung es, daß exportierte
Elemente veröffentlicht
werden. Eine solche Veröffentlichung
kann jedoch so geschehen, daß keine
privaten oder mit Eigentumsvorbehalt versehenen Elemente und Details
der Applets und zugehöriger
Bibliotheken offengelegt werden. Dadurch können verschiedene, getrennt
entwickelte Anwendungen auf ein ressourcenbegrenztes Gerät geladen
werden und ihre Komponenten können
gemeinsam verwendet werden, ohne private, sichere Information zu
beeinträchtigen.
-
Darüber hinaus
können
die Vorteile einer architekturneutralen Sprache, wie z.B. Java,
auf einem ressourcenbegrenzten Gerät realisiert werden, während ihre
Semantik erhalten bleibt. Die Token können auch für interne oder private Elemente
verwendet werden. Token können
also privaten und in der Verpackung sichtbaren Instanzenfeldern
ebenso wie in der Verpackung sichtbaren virtuellen Methoden zugeordnet
werden. Die Erfindung verlangt bei der Zuordnung von Token nur wenige
Einschränkungen
und die Token-Kategorien können
für bestimmte
Anwendungen weiter definiert oder optimiert werden. Insofern unterstützt die
Erfindung transportierbaren, architekturneutralen Code, der einmal
geschrieben wird und überall
läuft,
selbst auf hinsichtlich der Ressourcen beschränkten Geräten, wie z.B. Smart Cards mit
einer begrenzten Speicherkapazität.
-
ZEICHNUNGEN
-
1 veranschaulicht
die Umwandlung bzw. Konvertierung und das Laden von Code, der unabhängig von
einer Hardwareplattform ist, auf eine Smart Card.
-
2 zeigt
ein Computersystem, welches mit der Smart Card nach 1 kommuniziert.
-
3 zeigt
ein Diagramm, welches Abhängigkeiten
zwischen Paketen bzw. Verpackungen veranschaulicht.
-
4A und 4B sind
Diagramme, die zwei Umwandleroperationen veranschaulichen.
-
5 ist
ein Diagramm, welches zwei Pakete und ein Paketregister für das Auflösen statischer
Aufrufe zeigt.
-
6 ist
ein Flußdiagramm,
welches einen Verknüpfungsprozeß in Verbindung
mit den Paketen nach 5 zeigt.
-
7A–7I sind
Diagramme, welche verschiedene Klassen-, Feld- und Methodenaufrufe
veranschaulichen.
-
8A–8I sind Flußdiagramme, welche Prozesse
für das
Zuordnen von Token und die Unterstützung von Tabellen veranschaulichen.
-
9A–9C sind
Flußdiagramme,
welche Prozesse für
das Auflösen
von Token für
Instanzenfelder und -methoden veranschaulichen.
-
BESCHREIBUNG
-
Es
wird für
die Wiedergabe von Verknüpfungsinformation
für objektorientierte
Programme eine Methode in einem kompakten, sicheren Format beschrieben.
Unter Verwendung dieser Methode können die Programme auf eine
ressourcenbeschränkte
Einrichtung heruntergeladen, verknüpft und ausgeführt werden.
Ressourcenbeschränkte
Einrichtungen werden allgemein als solche angesehen, welche hinsichtlich
ihres Speichers oder Rechnerleistung oder -geschwindigkeit beschränkt sind.
Auch wenn die nachstehend diskutierte spezielle Implementierung
im Bezug auf eine Smart Card beschrieben wird, kann die Erfindung
auch mit anderen ressourcenbeschränkten Einrichtungen verwendet
werden, welche beispielsweise Mobiltelefone, Grenzpfadabtasteinrichtungen,
feldprogrammierbare Einrichtungen, persönliche Datenassistenten (PDAs) und
Pager umfassen, ebenso wie andere kleine oder Miniatureinrichtungen.
In einigen Fällen
hat die ressourcenbeschränkte
Einrichtung möglicherweise
nur 1 K an RAM oder nur 16 K ROM. In ähnlicher Weise beruhen einige
ressourcenbeschränkte
Einrichtungen auf einer Architektur, die für weniger als 32 Bit ausgelegt
ist. Beispielsweise beruhen einige der ressourcenbeschränkten Einrichtungen,
welche mit der Erfindung verwendet werden können, auf einer 8-Bit- oder
16-Bit-Architektur anstatt auf einer 32-Bit-Architektur.
-
Gemäß 1 beginnt
die Entwicklung eines Applets für
ein ressourcenbeschränktes
Gerät,
wie z.B. eine Smart Card 40, in einer Art und Weise, die
der Entwicklung eines Java-Programmes ähnlich ist. Mit anderen Worten,
ein Entwickler schreibt eine oder mehrere Java-Klassen und kompiliert
den Quellcode mit einem Java-Compiler, um eine oder mehrere Klassendateien 10 zu
erzeugen. Das Applet kann man laufen lassen, testen und nach Fehlern
durchsuchen, beispielsweise auf einer Workstation, die Simulationswerkzeuge
verwendet, um die Umgebung auf der Karte 40 zu emulieren.
Wenn das Applet für
das Herunterladen auf die Karte 40 bereit ist, werden die
Klassendateien 10 in eine konvertierte Applet(CAP)-Datei 16 umgewandelt,
und zwar durch einen Wandler bzw. Konverter 14. Der Konverter 14 kann
eine Java-Anwendung sein, die auf einem Desktopcomputer ausgeführt wird.
Der Konverter 14 kann als seine Eingangsgröße eine
oder mehrere Exportdateien 12 zusätzlich zu den konvertierten
Klassendateien 10 aufnehmen. Eine Exportdatei 12 enthält Namens-
und Verknüpfungsinformation
für die
Inhalte der anderen Pakete, die durch die Klassen importiert werden,
welche konvertiert werden.
-
Im
allgemeinen enthält
die CAP-Datei 16 alle Klassen und Schnittstellen, die in
einem einzelnen Java-Paket definiert sind, und wird durch einen
Strom von 8-Bit-Bytes wiedergegeben. Alle 16-Bit- und 32-Bit-Größen werden
aufgebaut, indem zwei bzw. vier aufeinanderfolgende 8-Bit-Bytes gelesen werden.
Unter anderem enthält
die CAP-Datei 16 eine Komponente eines Konstantenvorrates 18,
der getrennt von einer Methodenkomponente 20 verpackt ist.
Der Konstantenvorrat 18 kann verschiedene Typen von Konstanten
enthalten, einschließlich
Methoden- und Feldaufrufen,
die aufgelöst
werden, entweder wenn das Programm verknüpft oder auf die Smart Card 40 heruntergeladen
wird oder zum Zeitpunkt der Ausführung
durch die Smart Card. Die Methodenkomponente 20 spezifiziert
die Anbindungsbefehle, die in die Smart Card 40 heruntergeladen
und anschließend
durch die Smart Card ausgeführt
werden sollen.
-
Nach
der Umwandlung bzw. Konversion kann die CAP-Datei 16 auf
einem computerlesbaren Medium 17, wie z.B. einer Festplatte,
einer Diskette, einem optischen Speichermedium, einer Flasheinrichtung
oder irgendeinem anderen geeigneten Medium gespeichert werden. Oder
das computerlesbare Medium kann in Form einer Trägerwelle vorliegen, beispielsweise
einer Datenübermittlung
in einem Netzwerk, oder einem Datenverbindungsglied unter Verwendung
von Radiofrequenz (RF).
-
Die
CAP-Datei 16 kann dann an ein Terminal 22, wie
z.B. einen Desktop-Computer mit einem Kartenannahmegerät (CAD) 24 an
seiner Peripherie kopiert oder übertragen
werden. Das CAD 24 ermöglicht,
daß Information
in die Smart Card 40 geschrieben und von dieser wiedergewonnen
wird. Das CAD 24 enthält
einen Kartenanschluß (nicht
dargestellt), in welchen eine Smart Card 40 eingesetzt
werden kann. Wenn die Karte eingesetzt ist, drücken Kontakte von einem Anschluß gegen
den Oberflächenverbindungsbereich
auf der Smart Card 40, um Strom zu liefern und um Kommunikationen
mit der Smart Card zu ermöglichen,
auch wenn in anderen Implementierungen kontaktlose Kommunikationen
verwendet werden können.
Das Terminal 22 umfaßt
auch ein Installationswerkzeug 26, welches die CAP-Datei 16 für die Übermittlung
an die Karte 40 lädt. Die
Smart Card 40 hat einen Eingabe-/Ausgabe-(I/O)Anschluß 42,
welcher einen Satz von Kontakten enthalten kann, über welche
Programme, Daten und andere Kommunikationen bereitgestellt werden.
Die Karte 40 umfaßt
auch ein Installationswerkzeug 46 für den Empfang der Inhalte der
CAP-Datei 16 und das Herstellen des Applets für die Ausführung auf
der Karte 40. Das Installationswerkzeug 46 kann
beispielsweise als ein Java-Programm implementiert sein und kann
auf der Karte 40 ausgeführt
werden. Die Karte 40 hat ebenfalls einen Speicher, einschließlich eines
flüchtigen
Speichers, wie z.B. eines RAM 50. Die Karte 40 hat
außerdem einen
ROM 52 und nicht-flüchtigen
Speicher, wie z.B. ein EEPROM 54. Das durch die Steuerung 44 hergestellte
Applet kann in dem EEPROM 54 gespeichert werden.
-
In
einer bestimmten Anwendung wird das Applet durch eine virtuelle
Maschine 49 ausgeführt,
die auf einem Mikroprozessor 48 läuft. Die virtuelle Maschine 49,
die auch als virtuelle Java-Kartenmaschine bezeichnet werden kann,
muß die
CAP-Datei 16 nicht laden oder manipulieren. Statt dessen
führt die
virtuelle Java-Kartenmaschine 49 den Appletcode aus, der
zuvor als Teil der CAP-Datei 16 gespeichert wurde. Die
Aufteilung der Funktionalität
zwischen der virtuellen Java-Kartenmaschine 49 und dem
Installationswerkzeug 46 erlaubt, daß sowohl die virtuelle Maschine
als auch das Installationswerkzeug relativ klein gehalten werden können.
-
Im
allgemeinen folgen die Implementierungen und Applets, die für eine ressourcenbeschränkte Plattform
wie z.B. die Smart Card 40 geschrieben werden, den Standardregeln
für Pakete
auf der Java-Plattform. Die virtuelle Java-Maschine und die Java-Programmiersprache
werden in dem Dokument T. Lindholm et al., "The Java Virtual Machine Specification" (1997) und K. Arnold
et al., "The Java
Programming Language Second Edition" (1998) beschrieben, die hier in ihrer
Gesamtheit durch diese Bezugnahme aufgenommen werden. Die Klassen
der Anwendungsprogrammierschnittstelle (API) für die Plattform der Smart Card
können
als Java-Quelldateien geschrieben werden, die Paketbestimmungen
enthalten, wobei ein Paket eine Anzahl von Kompilierungseinheiten
enthält
und einen eindeutigen Namen hat. Paketmechanismen werden verwendet,
um den Zugriff auf Klassen, Felder und Methoden zu identifizieren
und zu kontrollieren. Die Java Card API ermöglicht es, daß Anwendungen
für eine
für Java-Karten
freigegebene Plattform geschrieben werden, so daß sie auf irgendeiner anderen
für eine
Java-Karte freigegebenen Plattform laufen. Zusätzlich ist die Java-Karten-API mit
formalen, internationalen Standards, wie z.B. ISO 7816, und industriespezifizierten
Standards wie Europay/Mastercard/Visa (EMV) kompatibel.
-
Auch
wenn die virtuelle Maschine 49, welche auf einem Mikroprozessor 48 läuft, als
eine Implementierung für
die Ausführung
der Bytecodes auf der Smart Card 40 beschrieben wurde,
kann ein anwendungsspezifischer integrierter Schaltkreis (ASIC)
oder eine Kombination einer Hardware und einer Firmware statt dessen
verwendet werden.
-
Gemäß 1 verwendet
die Steuerung 44 ein Installationswerkzeug 46 für die Aufnahme
der Inhalte der CAP-Datei 16 und die Herstellung des durch
einen Prozessor 48 auszuführenden Applets. Das Installationswerkzeug 46 kann
beispielsweise als ein Java-Programm implementiert werden, welches
in geeigneter Weise so konvertiert wurde, daß es auf der Smart Card 40 abläuft. In
der nachstehenden Beschreibung ist angenommen, daß die Steuerung 44 ein
Programm 49 einer virtuellen Maschine aufweist, das auf
einem Mikroprozessor 48 läuft. Die virtuelle Maschine 9 (fehlt
hier eine 4?) muß die
CAP-Datei 16 weder laden noch manipulieren. Statt dessen
führt die
virtuelle Maschine 49 den Appletcode in der CAP-Datei 16 aus.
Die Aufteilung der Funktionalität
zwischen der virtuellen Maschine 49 und dem Installationswerkzeug 46 erlaubt
es, daß sowohl
die virtuelle Maschine als auch das Installationswerkzeug relativ
klein gehalten werden können.
In alternativen Implementierungen kann die Steuerung beispielsweise
als anwendungsspezifischer integrierter Schaltkreis (ASIC) hart
verdrahtet sein, oder sie kann als eine Kombination aus Hardware
und Firmware implementiert sein.
-
Die
Plattform der Smart Card, welche ebenso auch für andere ressourcenbeschränkte Einrichtungen verwendet
werden kann, unterstützt
dynamisch erzeugte Objekte, einschließlich sowohl von Klasseninstanzen als
auch von Arrays. Eine Klasse ist implementiert als eine Erweiterung
oder Unterklasse einer einzelnen existierenden Klasse, und ihre
Mitglieder sind Methoden ebenso wie Variable, die als Felder bezeichnet
werden. Eine Methode deklariert ausführbaren Code, der aufgerufen
werden kann und dann eine feste Anzahl von Werten als Argumente
durchläuft.
Klassen können
auch Java-Schnittstellen implementieren. Eine Schnittstelle ist ein
Referenz- bzw. Aufruftyp, dessen Mitglieder Konstanten und abstrakte
Methoden sind. Die virtuelle Maschine 49 kann einen Übersetzer
(Interpreter) oder eine ursprüngliche
(native) Implementierung enthalten, die Zugriff auf ein Laufzeitsystem
gewährt,
welches die Java-Karten-API umfaßt und Funktionalitäten unterstützt.
-
Wie
in 2 dargestellt, ist ein Computer 221 mit
einem Kartenannahmegerät 24 für die Aufnahme der
Karte 40 nach 1 ausgestattet. Der Computer 22 kann
mit einem Netzwerk 45 verbunden sein, welches mit einer
Mehrzahl anderer Rechnereinrichtungen, wie z.B. einem Server 47,
in Kommunikationsverbindung steht. Es ist möglich, Daten und Software über das
Netzwerk 45 über
mit Karten ausgestattete Geräte
auf eine Smart Card zu laden. Downloads dieser Art können Applets
oder andere Programme enthalten, die auf eine Smart Card geladen
werden sollen, ebenso wie digitales Bargeld und andere Informationen,
die mit einer Vielfalt elektronischer Handels- und anderer Anwendungen
verwendet werden. Die Befehle und Daten, die verwendet werden, um
Verarbeitungselemente der Kartenannahmeeinrichtung und der Smart
Card zu steuern, können
auf flüchtigem
oder nicht-flüchtigem
Speicher gespeichert werden oder können direkt über eine
Kommunikationsverbindung, z.B. als eine Trägerwelle, welche die Befehle
und/oder Daten enthält,
direkt empfangen werden. Weiterhin kann das Netzwerk 45 beispielsweise
ein LAN oder ein WAN, wie z.B. das Internet oder ein anderes Netzwerk
sein.
-
3 zeigt
ein Diagramm, welches typische hierarchische Abhängigkeiten zwischen einer Gruppe von
Programmpaketen (einschließlich
sowohl von Anwendungsprogrammschnittstellen (APIs) und Programmapplets)
veranschaulicht, die auf eine Smart Card 40 geladen werden.
Anwendungen können
auf die Smart Card 40 schrittweise geladen werden und auf
der Karte für
die Ausführung
verknüpft
werden, so daß die
Funktionalität
der Smart Card mit zusätzlichen
Fähigkeiten
zusätzlich
zu den bei der Herstellung programmierten Funktionalitäten aktualisiert
werden kann. In dem Diagramm liegen der Java-Sprachenrahmen 50 und ein
Java-Kartenrahmen 52 als eine API-Ebene der Java-Karte vor. Oberhalb der
API-Ebene der Java-Karte befindet sich eine spezifische bzw. maßgeschneiderte
API-Ebene mit einem oder mehreren maßgeschneiderten Rahmen bzw.
Grundaufbauten 54. Der maßgeschneiderte Grundaufbau 54 kann
durch einen oder mehrere, den Wert erhöhende Provider über verschiedene
Softwareentwicklungssätze
(Software Development Kits – SDKs)
zur Erweiterung eines existierenden Grundrahmens oder einer anderen
API zugeführt
werden. Auf der höchsten
Ebene befindet sich eine Anwendungsebene, auf der verschiedene Applets 56, 58 und 60 ruhen.
-
Wie
in 3 dargestellt, kann ein Paket von anderen Paketen
auf derselben API-Ebene oder von solchen Paketen in niedrigeren
API-Ebenen abhängen.
Beispielsweise kann sich das Applet 58 auf Programmelemente
in dem Applet 58 beziehen und das Grundgerüst 52 der
Java-Karte kann
Abhängigkeiten
von dem Grundgerüst 50 in
der Java-Sprache haben. Darüber
hinaus kann das maßgeschneiderte
Grundgerüst 54 auf der
entsprechenden API-Ebene, und ebenso wie die Applets 58 und 60,
Referenzen haben, die von dem Grundgerüst 52 der Java-Karte
abhängen.
Die Applets 56 und 58 können ihrerseits Referenzen
haben, welche von dem maßgeschneiderten
bzw. kundenspezifischen Grundgerüst 54 abhängen. Das
Applet 56 und das maßgeschneiderte
Grundgerüst 54 können auch
von dem Grundgerüst 50 in
der Java-Sprache abhängen. Auch
wenn das Beispiel nach 3 lineare Abhängigkeiten
zeigt, können
nicht-lineare Abhängigkeiten,
wie z.B. ringförmige
Abhängigkeiten,
unter Verwendung eines geeigneten Konverters 14 und geeigneter
Installationswerkzeuge 46 unterstützt werden.
-
Die
Umwandlung eines Satzes von Klassendateien von beispielsweise einer
Java-Anwendung auf eine
CAP-Datei kann bei der Vorbereitung für die Installation auf einer
Smart Card 40 allgemein auf einem Desktop-Computer erfolgen.
Der Desktop-Computer 22 ist üblicherweise nicht so in seinen
Ressourcen eingeschränkt
wie eine typische Smart Card 40. Außerdem kann die Umwandlungsoperation
ebensogut auf anderen geeigneten Plattformen ausgeführt werden.
-
4A zeigt
ein System zum Umwandeln bzw. Konvertieren eines Paketes, welches
ein Applet oder eine Bibliothek in Vorbereitung für das Herunterladen
auf die Smart Card 40 definieren kann. Der Konverter bzw.
Wandler 72 empfängt
eine Dateneingangsgröße von einer
oder mehreren Klassendateien 40, welche die Funktionalität eines
Applets definieren. Der Konverter 72 erzeugt seinerseits
eine Java-Karten-CAP-Datei 74, die für ein Herunterladen geeignet
ist.
-
Wie
unten genauer erläutert
wird, enthält
die CAP-Datei 74 eine Exportkomponente 82 für das Auflösen von
Aufrufen an Elemente in seinem Paket, wobei auf diese Elemente auch
durch andere Pakete aufgerufen werden können. Die Exportkomponente 82 enthält Einträge für statische
Gegenstände,
wie z.B. Klassen, Methoden und Felder. Referenzen auf dynamische
Gegenstände,
wie z.B. Instanzenfelder, virtuelle Methoden und Schnittstellenmethoden
müssen
nicht in der Exportkomponente präsentiert
werden, können
jedoch entsprechend den nachstehend beschriebenen Vorgängen gehandhabt
werden.
-
In
ressourcenbeschränkten
Einrichtungen verbraucht die Verwendung von Unicode-Strings für die Repräsentation
von Gegenständen
Speicher- und Prozessorressourcen. Anstelle von Strings bildet die
Exportkomponente 82 Token oder einfache eindeutige numerische
Werte auf bestimmte Elemente ab, die in anderen Komponenten in der
CAP-Datei 74 definiert sind. Die Tokenwerte, die verwendet
werden, um diese Elemente in der Exportkomponente zu repräsentieren,
passen zu denjenigen, die in einer entsprechenden Exportdatei 80 veröffentlicht
werden.
-
Genauer
gesagt hat die CAP-Datei 74 unter anderem eine Kopfzeilen-(Header)Komponente 76,
einen Konstantenvorrat 78, eine Methodenkomponente 80 und
eine Exportkomponente 78. Der Konstantenvorrat 78 enthält typischerweise
eine oder mehrere Klassen-, Feld- und Methodenaufrufe, so daß im allgemeinen
Aufrufe von Programmelementen oder Gegenständen indirekt über den
Konstantenvorrat 78 des Paketes vorgenommen werden. Die
Methodenkomponente 80 enthält alle Methoden, die durch
das Appletpaket implementiert werden, welches durch die CAP-Datei 74 wiedergegeben
wird. Methodenaufrufe lösen
Methoden auf, die in der Methodenkomponente angesiedelt sind. Klassenaufrufe
und statische Feldaufrufe lösen
sich auf zu Positionen bzw. Anordnungen in Klassenkomponenten bzw.
statischen Feldkomponenten.
-
Die
Exportkomponente 78 enthält einen oder mehrere Einträge mit einem
Tokenwert 84 und entsprechender Programmelementverknüpfungsinformation 86,
welche beschreibt, wo in dem in der CAP-Datei A 74 definierten
Paket ein bestimmtes Programmelement gefunden werden kann. Die Verknüpfungsinformation
ist für
den Inhalt der CAP-Datei 74 spezifisch, jedoch nicht die
interne Repräsentation
auf einer bestimmten Karte. Diese Komponente beschreibt deshalb
nicht kartenspezifische private oder sichere Informationen.
-
Der
Konverter bzw. Wandler 72 kann während der Umwandlung von Klassendateien
in eine CAP-Datei 74 auch eine Exportdatei 80 erzeugen.
Eine Exportdatei wird für
jede CAP-Datei erzeugt. Die Exportdatei 80 hat typischerweise
einen oder mehrere Einträge
mit einem symbolischen Namen 90 für ein bestimmtes Programmelement
in der CAP-Datei 74 und seinen entsprechenden Tokenwert 92.
Die Exportdatei 80 stellt Informationen zu jedem extern
zugänglichen
Programmelement des Paketes von Klassendateien und Programminformationen
in der CAP-Datei 74 bereit, die durch ein zweites Paket
aufgerufen bzw. in eine zweite CAP-Datei importiert werden kann
(wird im folgenden noch genauer beschrieben). Beispielsweise enthält die Exportdatei 80 Aufrufe
an alle öffentlichen
Klassen und Schnittstellen, die in einem Java-Paket definiert sind,
und alle öffentlichen
und geschützten
Felder und Methoden, die in diesen Klassen und Schnittstellen definiert
sind. Die Exportdatei 80 enthält auch eine Zuordnung dieser
Programmelemente oder Gegenstände
zu Token, welche dann verwendet werden können, um während der Paketkonversion Namen
für importierte
Gegenstände
auf Token abzubilden bzw. Token zuzuordnen. Die Exportdatei legt
keine privaten oder im Eigentum befindlichen Einzelheiten der Applets
und zugehörigen
Bibliotheken offen. Dadurch können
verschiedene, getrennt entwickelte Anwendungen auf eine ressourcenlimitierte
Einrichtung geladen werden und sie können ihre Komponenten miteinander
gemeinsam verwenden, ohne private, sichere Informationen zu beeinträchtigen.
Die Exportdatei 80 legt keine privaten oder im Eigentum
befindlichen Elemente und Einzelheiten der Applets der dazugehörigen Bibliotheken
frei, getrennt entwickelte Anwendungen können auf die Karte 40 geladen
werden und ihre exportierten Elemente mit anderen gemeinsam verwenden,
ohne private, sichere Informationen zu beeinträchtigen.
-
Gemäß den 3 und 4A würde die
während
der Konversion erzeugte Exportdatei 80, wenn eine Anzahl
von Klassendateien 70, die ein Java-Karten-Grundgerüst API 52 aufweisen,
konvertiert werden, es zulassen, daß andere Applet-Programme,
die getrennt konvertiert werden, wissen, welche Token verwendet
werden müssen,
um Gegenstände
der Java-Grundgerüst
API extern aufzurufen. Wenn beispielsweise ein Applet die Grundgerüstklasse
PIN aufruft, so enthält
die Exportdatei 80 für
das Java-Karten-Grundgerüst
einen Eintrag für
die Klasse Javacard.Grundgerüst.PIN
(Javacard.Framework.PIN), zusammen mit deren entsprechendem Token.
Der Konverter 72 würde
dieses Token in dem Konstantenvorrat der CAP-Datei des neuen Applets anordnen,
wo es einen nicht aufgelösten
Aufruf der Klasse in dem Grundgerüst repräsentiert. Wie unten noch weiter
erläutert
wird, kann während
der Appletausführung
das Token verwendet werden, um den aufgerufenen Gegenstand in der
Exportkomponente 78 des Grundgerüst API-Paketes zu lokalisieren,
um die Elementverknüpfungsinformation
zu gewinnen. Beispielsweise kann die Verknüpfungsinformation einer Methode
Informationen bereitstellen, um die geeignete Methode zu lokalisieren,
die in der Methodenkomponente 80 dieses Paketes enthalten
ist.
-
4B zeigt
den Wandler 72, welcher ein zweites Paket von Klassendateien 94 umwandelt,
wobei diese Klassendateien 94 Elemente von den Klassendateien
des ersten Paketes 70 (4A) importieren.
Beispielsweise kann das zweite Paket ein Satz von Appletklassen
sein, die auf gewissen Klassen beruhen, welche beispielsweise in
einem Bibliothekspaket "Javacard.Framework" (Javacard-Grundgerüst) enthalten
sind, welches zuvor konvertiert wurde (wie es oben unter Bezug auf 4A beschrieben
wurde. Der Konverter 72 empfängt Dateneingangsgrößen von
den Klassendateien 94 und von einer oder mehreren Exportdateien 80 aus zuvor
umgewandelten Paketen. Der Konverter 72 erzeugt eine CAP-Datei 100,
die für
das Herunterladen beispielsweise auf die Smart Card 40 geeignet
ist.
-
Die
CAP-Datei B 100 für
das zweite Paket enthält
eine Importkomponente 104 mit einer Liste aller Pakete,
welche durch die Appletklassen aufgerufen werden. Jeder derartige
externe Paketaufruf weist eine Zuordnung 106 zwischen einem
internen Paket-Token und einer externen, eindeutigen Anwendungskennung (AID)
für dieses
Paket auf. Jedes Paket-Token wird in anderen Komponenten innerhalb
der CAP-Datei 100 verwendet, um ein bestimmtes, aufgerufenes,
externes Paket klar zu identifizieren und dadurch den Größenumfang
der Repräsentation
des Applet zu reduzieren.
-
Die
CAP-Datei 100 hat u.a. auch eine Kopfzeilenkomponente 102 (Header),
eine Importkomponente 104 und einen Konstantenvorrat 108.
Der Konstantenvorrat 108 enthält einen oder mehrere Klassenaufrufe 110,
welche jeden Klassenaufruf entsprechenden Paket-Token und Klassen-Token
zuordnen und dadurch die spezifizierte Klasse auf ihr entsprechendes
externes Paket und die Klassen innerhalb dieses Paketes abbilden.
Die Verwendung dieser Token ist unten noch genauer beschrieben.
Der Konstantenvorrat 108 kann auch einen oder mehrere Methodenaufrufe 112 umfassen,
welche in ähnlicher
Weise jeden Methodenaufruf entsprechenden Paket-Token, Klassen-Token
und Methoden-Token zuordnen. Der Konstantenvorrat 108 kann auch
einen oder mehrere Feldaufrufe 114 umfassen, jeden mit
seinem Paket-Token bzw. Klassen-Token bzw. Feld-Token.
-
Im
allgemeinen erfolgen Aufrufe von Programmelementen oder Gegenständen indirekt
durch den Konstantenvorrat 108 jedes Paketes. Aufrufe von
Gegenständen
in anderen Paketen werden extern genannt und werden durch Token
ausgedrückt
bzw. wiedergegeben. Aufrufe von Gegenständen in derselben CAP-Datei
werden intern genannt und können
entweder in Form von Token oder in einem anderen internen Format (wie
z.B. in Form von Zeigern auf Positionen innerhalb der CAP-Datei)
repräsentiert
werden. Beispielsweise besteht der externe Aufruf 110 einer
Klasse aus einem Paket-Token und einem Klassen-Token. Zusammen spezifizieren
diese Token eine bestimmte Klasse in einem bestimmten externen Paket.
Ein interner Aufruf einer Klasse kann ein Zeiger auf die Position
der Struktur der Klasse innerhalb der CAP-Datei sein. Alternativ
kann das externe Tokensystem auch intern verwendet werden. Die externen
Aufrufe 112–114 beziehen
sich auf ein statisches Klassenmitglied, entweder ein Feld oder
eine Methode, mit einem Paket-Token, einem Klassen-Token und einem
Token für
das statische Feld oder die statische Methode. Ein interner Aufruf
eines statischen Klassenmitgliedes kann ein Zeiger auf die Position
des Gegenstandes in der CAP-Datei sein, kann jedoch auch das Tokensystem
verwenden. Aufrufe von Instanzenfeldern, virtuellen Methoden und
Schnittstellenmethoden bestehen aus einem Klassenaufruf und einem
Token des geeigneten Typs. Der Klassenaufruf zeigt an, ob der Aufruf
extern oder intern ist.
-
Externe
Aufrufe in einer CAP-Datei können
auf einer Karte aus der Tokenform in die interne Wiedergabe aufgelöst werden,
welche durch die virtuelle Java-Kartenmaschine verwendet wird. Ein
Token kann nur in dem Kontext des Paketes aufgelöst werden, das es definiert
hat. Ebenso wie die Exportdatei Abbildungen von den extern sichtbaren
Namen eines Paketes auf Token abbildet bzw. zuordnet, gibt es einen
Satz von Verknüpfungsinformationen
für jedes
Paket auf der Karte, welches von Token auf aufgelöste Aufrufe
abbildet. In dieser Weise verarbeitet der Wandler 97 sowohl
die Klassendateien 92 als auch die Expordatei 94,
erzeugt ein zum Herunterladen des Applets auf eine ressourcenbegrenzte
Einrichtung geeignetes Bild und löst Aufrufe (Verknüpfungen)
zu dem ersten Paket auf.
-
Nach
der Vorverarbeitung, die in den 4A und 4B durchgeführt wurde,
kann die CAP-Datei nach 4B auf
die Smart Card 40 oder eine ressourcenbeschränkte Einrichtung
heruntergeladen werden, welche die CAP-Datei nach 4A enthält. Die 5 und 6 veranschaulichen
genauer, wie eine tokenbasierte Verknüpfung für statische Elemente auf der
Smart Card 40 oder einer kleinen Einrichtung erfolgt. Die statischen
Elemente enthalten Elemente, deren genaue Repräsentationen während des
Wandlungsprozesses durch den Konverter identifizierbar sind.
-
In 5 ist
ein Bild 200 eines Paketes P2, beispielsweise von einer
CAP-Datei B 100, auf eine Karte 40 geladen worden
und kann vor oder während
der Ausführung
mit einem früheren
Paket P1 verknüpft
werden. Programmelemente in dem Paket P2 200 können Aufrufe
von Methoden und anderen Daten in dem externen Paket P1 enthalten,
welches bereits als ein Bild bzw. Abbild 174 auf der Karte 40 (der
CAP-Datei A 74) existiert. Das Bild 174 enthält u.a.
eine Kopfzeilenkomponente 176, einen Konstantenvorrat 178,
eine Methodenkomponente 180 und eine Exportkomponente 182,
welche eine Liste von Token für
alle exportierten statischen Gegenstände 185 enthält. Um die
Auflösung
des Aufrufs an ein externes Paket aufzulösen, wird ein Paketregister 120 auf
der Karte 40 erzeugt, um Informationen bereitzustellen,
die verwendet werden, um eines oder mehrere externe Pakete zu lokalisieren,
einschließlich
des Bildes 174 des Paketes P1, welches bestimmte Methoden enthält, die
für das
Bild 200 des Paketes P2 erforderlich sind.
-
Das
Bild 200 des Paketes P2 enthält u.a. eine Kopfzeilenkomponente
(Header) 202, eine Importkomponente 204, einen
Konstantenvorrat 208 und eine Methodenkomponente 216,
die allesamt den entsprechenden Komponenten 102, 104, 108 bzw. 116 in
der CAP-Datei B 100 entsprechen. Die generelle Organisation dieser
Komponenten wird oben unter Bezug auf die CAP-Dateien beschrieben. Typischerweise
enthält
die Methodenkomponente 216 Programmaufrufe, wie z.B. "neu" bzw. "new" (218), "invoke static" (220) und "get static_b" (222),
zusammen mit ihren entsprechenden aufgerufenen Klassenaufrufen,
Methodenaufrufen und Feldaufrufen.
-
6 zeigt
einen Linkprozeß (140)
für das
Paket P2 200 nach 5. Wenn
eine in der Methodenkomponente 216 ablaufende Methode eine
bestimmte Methode, z.B. die Methode T in der Methodenkomponente 180,
aufruft, die in einem externen Paket (Package 1) angeordnet ist,
ist eine Verknüpfung
(Link) erforderlich (Schritt 142). Unter Verwendung des
Index, der als Operand für
den Befehl bereitgestellt ist, lokalisiert der Prozeß 140 den
passenden Methodenaufruf 212 und beschafft ihn aus dem
Konstantenvorrat 208 (Schritt 144). Wie unten
beschrieben, besteht der Methodenaufruf aus einem Paket-Token, einem
Klassen-Token und einem Methoden-Token, die verwendet werden, um
die betreffende Methode in einem externen Paket zu lokalisieren.
Als nächstes
untersucht der Prozeß 140 die
Importkomponente 204, um den eindeutigen AID des externen
Paketes P1 auf der Basis des gewonnenen Paket-Token zu finden (Schritt 146).
Es wird dann das Paketregister 120 untersucht, um die Position
des Paketes P1 auf der Basis des AID zu finden (Schritt 148).
Wenn das Bild 174 für
das Paket P1 aus dem Paketregister 120 gefunden wurde,
wird die Exportkomponente 182 des Bildes 174 gesucht,
um die Klasse mit dem angegebenen Klassen-Token zu lokalisieren
(Schritt 150). Die Programmverknüpfungsinformation für die gewünschte Methode,
z.B. die Methode T, wird dann gefunden, indem man die Liste von
Methoden durchsucht, die zu der betreffenden, in Schritt 150 gefundenen
Klasse gehört,
um die Methode mit dem beschriebenen Methoden-Token (hier entspricht
das Methoden-Token Y der Methode T des Paketes P1 174)
zu lokalisieren (Schritt 152). Schließlich wird die Position der
beschriebenen Methode, z.B. Methode T, in der Methodenkomponente 180 auf
der Basis der Verknüpfungsinformation
bestimmt, die für
die Methode in der Exportkomponente 182 bereitgestellt
wurde (Schritt 154).
-
Unter
Verwendung des Prozesses laut 6 kann ein
Paket auf eine Karte heruntergeladen und für die Ausführung durch eine virtuelle
Maschine vorbereitet werden. Dieser Prozeß wird "Installation" genannt. Es können verschiedene Installationsprozesse
verwendet werden, die sich in der Reihenfolge der Verarbeitung und
in den Verknüpfungsoperationen
unterscheiden (wann die Daten auf der Karte empfangen werden und wann
sie gespeichert werden). Diese Installationsvorgänge können auf der Basis der verfügbaren Ressourcen auf
der Karte optimiert werden. In einer Implementierung erfolgt keine
Verknüpfung
und insofern werden Daten, wenn sie empfangen werden, sofort gespeichert.
Während
der Interpretation oder Ausführung
des Codes erfolgt eine Auflösung
externer Aufrufe. Insoweit wird diese Implementierung in einer größeren (weniger
beschränkten)
kleinen Einrichtung verwendet, da sämtliche temporäre Verknüpfungsinformation
dauerhaft auf dieser Karte gespeichert wird.
-
Wie
oben erläutert,
werden anstelle von Unicode-Strings, wie sie in Javaklassendateien
verwendet werden, Token verwendet, um Gegenstände in einer CAP-Datei zu identifizieren
und um Aufrufe auf der ressourcenbeschränkten Einrichtung aufzulösen. Token
für einen
API werden durch den API-Entwickler zugewiesen und in der Exportdatei
(den Exportdateien) für
den API veröffentlicht.
Da die Zuordnungen von Namen zu Token veröffentlicht werden, kann ein
API-Entwickler innerhalb
der durch die Erfindung gegebenen Einschränkungen jegliche Reihenfolge
für Token
auswählen.
-
Gemeinsam
beschreiben die 5 und 6 die Auflösung von
Aufrufen von statischen Gegenständen,
d.h. Klassen, statischen Feldern und statischen Methoden. Die Implementierungen
dieser Gegenstände sind
während
der Kompilierung und Konversion vollständig lokalisierbar. Im Gegensatz
dazu sind während
der Kompilierung und Konversion Aufrufe von Instanzenfeldern, virtuellen
Methoden und Schnittstellenmethoden nicht an bestimmte Implementierungen
statisch gebunden. Diese Gegenstände
erfordern zusätzliche
Information, die nur unter Bezug auf eine Instanz zur Laufzeit verfügbar ist.
Die Auflösung
von Aufrufen dieser Typen wird in Bezug auf die 9A–9C beschrieben.
-
Tokenzuweisungen
für virtuelle
Methoden erhalten die Beziehungen innerhalb objektorientierter Klassenhierarchien.
Token für
virtuelle Methoden und Schnittstellenmethoden werden als Indizes
in virtuellen Methodentabellen bzw. Schnittstellenmethodentabellen
verwendet. Eine besondere Kartenplattform kann ein Token in einer
internen Repräsentation
auflösen,
die für
die betreffende Implementierung der VM einer ressourcenbeschränkten Einrichtung
besonders zweckmäßig ist.
-
Einige
Token können
zu Indizes aufgelöst
werden. Beispielsweise kann ein Instanzenfeld-Token zu einem Index in einer Klasseninstanz
aufgelöst
werden. In derartigen Fällen
kann der Tokenwert von dem Wert des aufgelösten Index verschieden und
ohne Beziehung zu diesem sein.
-
Jede
Art von Gegenstand in einem Paket hat ihren eigenen, unabhängigen Umfang
bzw. Rahmen für Token
dieser Art. Beispielhafte Tokenbereichs- und Zuweisungsregeln für jede Art
von Aufruf sind nachstehend aufgelistet. Es können auch andere Bereiche und
Zuweisungen von Token vorgenommen werden.
-
-
Die 7A–7I sind
Diagramme, welche Repräsentationen
von Aufrufen veranschaulichen. Die 7A–7C beschreiben
Aufrufe von importierten Elementen, während die 7D–7I Aufrufe
von internen Gegenständen
beschreiben, von denen einige ebenfalls Token verwenden.
-
7A zeigt
einen Klassenaufruf an eine externe Klasse 180. Der Klassenaufruf
nach 7A enthält ein
Paket-Token und ein Klassen-Token. 7B zeigt
eine Repräsentation
eines externen Feldaufrufs. Der externe Feldaufruf 182 enthält ein Paket-Token,
ein Klassen-Token und ein Feld-Token. 7C zeigt
eine Repräsentation
einer externen Methodenreferenz 184. Die externe Referenz 184 enthält ein Paket-Token,
ein Klassen-Token und ein Methoden-Token. Es versteht sich, daß für virtuelle
Methoden das hohe Bit des Methoden-Token auf Null gesetzt wird.
Das Setzen des hohen Bit zeigt an, daß auf die Methode Zugriff von
außerhalb des
definierenden Paketes besteht. Das hohe Bit kann das am meisten
signifikante Bit sein, wie z.B. das siebte Bit eines Byte, das fünfzehnte
Bit eines Wortes oder das dreiundzwanzigste Bit einer Drei-Byte-Einheit.
-
Das
hohe Bit eines Paket-Token wird so eingestellt, daß es ein
importiertes Paket anzeigt. Dieses wird verwendet, um zwischen externen
und internen Aufrufen zu unterscheiden. Wie in den 7D–7I dargestellt,
sind bei Aufrufen von internen Elementen die hohen Bits auf Null
gesetzt. Die Formate der 7D–7I sind
Beispiele der Ausweitung der Tokenverwendung in ausgewählten Fällen auf
interne Gegenstände.
-
7D zeigt
eine Wiedergabe bzw. Repräsentation
eines internen Klassenaufrufs 186. Der interne Klassenaufruf 186 umfaßt eine
Verschiebung auf eine bzw. von einer Klasseninformationsstruktur
in der Klassenkomponente. 7E zeigt
eine Repräsentation
eines statischen Feldaufrufs 188 für ein internes Feld. Insofern
hat der statische Feldaufruf 188 ein Feld, welches auf
Null gesetzt wird, und ein Feld für das Einbeziehen eines Versatzes
für ein
statisches Feld in dem Bild des statischen Feldes. 7F ist
eine Repräsentation eines
statischen Methodenaufrufs 190 für interne Methoden. Der statische
Methodenaufruf 190 enthält
ein Feld zur Pufferung, welches auf Null besetzt ist, damit der
Aufruf dieselbe Größe hat wie
ein importierter Methodenaufruf. Der statische Methodenaufruf 190 enthält auch
ein Feld, welches Information bereitstellt, die sich auf einen Versatz
(Offset) für
eine statische Methode in der Methodenkomponente bezieht.
-
7G zeigt
eine Repräsentation
eines Instanzenfeldaufrufs 192 für ein internes Feld. In 7G enthält der Instanzenfeldaufruf 192 einen
Versatz bzw. ein Offset einer Klasseninformationsstruktur in der
Klassenkomponente, ebenso wie ein Feld-Token. 7H zeigt
einen virtuellen Methodenaufruf 194 an eine öffentliche
oder geschützte
Methode für
eine interne Methode. Der virtuelle Methodenaufruf 194 enthält einen
Versatz (Offset) zu einer Klasseninformationsstruktur in der Klassenkomponente,
ein Feld, welches gelöscht
wird, um eine extern zugängliche
virtuelle Methode anzuzeigen und um eine Übereinstimmung mit dem Format
in 7C zu erreichen. Der virtuelle Methodenaufruf 194 enthält auch
ein Methoden-Token.
-
Schließlich zeigt 7I eine
Repräsentation
eines virtuellen Methodenaufrufs 196 an eine im Paket sichtbare
Methode für
interne Methoden. Der virtuelle Methodenaufruf 196 enthält einen
Versatz (Offset) zu der Klasseninformationsstruktur und der Klassenkomponente,
ein Feld, welches auf Eins gesetzt wird, was anzeigt, daß der Umfang
des Aufrufs für
das Paket intern ist. Der Aufruf 196 enthält auch
ein Methoden-Token.
-
Die 8A–8I sind Flußdiagramme, welche Prozesse
für die
Zuweisung von Token und den Aufbau virtueller Methodentabellen und
Schnittstellenmethodentabellen veranschaulichen. Diese Prozesse
können durch
einen Konverter bzw. Wandler 72 durchgeführt werden,
wie es oben erläutert
wird. Gemäß 8 ist ein Prozeß 230 für die Zuweisung
von Paket-Token dargestellt. Generell sind Paketaufrufe aus dem
Inneren einer CAP-Datei zugewiesene Token, welche nur in der CAP-Datei
verwendet werden.
-
Der
Prozeß 230 erhält zunächst eine
Liste von importierten Paketen (Schritt 231). Die Liste
kann in irgendeiner Reihenfolge vorliegen. Als nächstes prüft der Prozeß 230,
ob die Anzahl von Paketen, die importiert werden, den vorbestimmten
Grenzwert, wie z.B. 127, überschreitet
(Schritt 232). In diesem Fall wird ein Grenzwert von 127
verwendet, um ein Paket-Token in 8-Bits wiederzugeben, wobei das
hohe Bit reserviert bleibt. Wenn die Anzahl importierter Pakete
den vorbestimmten Grenzwert, wie z.B. 127, überschreitet, schlägt der Prozeß fehl (Schritt 205).
-
Alternativ
initialisiert der Prozeß 230 den
aktuellen Tokenwert auf Null (Schritt 233). Als nächstes initialisiert
der Prozeß 230 das
aktuelle Paket auf das erste Paket in der Liste (Schritt 234).
Der Prozeß 230 überprüft dann,
ob das aktuelle Paket leer ist (Schritt 235). Falls nicht,
weist der Prozeß 230 das
aktuelle Token dem aktuellen Paket zu (Schritt 236). Als
nächstes
setzt der Prozeß 230 den
aktuellen Tokenwert um eins herauf (Schritt 237) und setzt
das aktuelle Paket auf das nächste
Paket in der Liste (Schritt 238).
-
Aus
Schritt 235 zeichnet in dem Fall, daß das aktuelle Paket leer bzw.
ein Null-Paket ist, was anzeigt, daß es keine weiteren importierten
Pakete mehr gibt, der Prozeß 230 das
Token in einer Importkomponente auf (Schritt 239) und endet.
Aufrufe von Gegenständen
in importierten Paketen verwenden Tokenwerte, die in der Importkomponente
aufgezeichnet sind.
-
Gemäß 8B ist
ein Prozeß 240 für das Zuweisen
von Klassen- und Schnittstellen-Token dargestellt. Der Prozeß 240 erhält zunächst eine
willkürlich
geordnete Liste öffentlicher
Klassen und Schnittstellen (Schritt 241). Als nächstes überprüft er, ob
die Anzahl von Klassen und Schnittstellen einen vorbestimmten Wert,
wie z.B. 256, überschreitet,
was die maximale Anzahl von Klassen ist, die in 8-Bits repräsentiert
werden können
(Schritt 242). Wenn dies der Fall ist, schlägt der Prozeß 240 fehl
(Schritt 205). Alternativ initialisiert der Prozeß 240 den
aktuellen Tokenwert auf Null (Schritt 243). Er initialisiert
auch den aktuellen Gegenstand auf die erste Klasse oder Schnittstelle
in der in Schritt 241 erhaltenen Liste (Schritt 244).
Als nächstes
bestimmt der Prozeß 240,
ob der aktuelle Gegenstand Null ist, was anzeigt, daß keine
weiteren Klassen oder Schnittstellen in der Liste verblieben sind
(Schritt 245). Falls nicht, ordnet der Prozeß 240 dem
aktuellen Gegenstand einen aktuellen Tokenwert zu, wobei der Gegenstand
eine Klasse oder ein Schnittstellengegenstand sein kann (Schritt 246).
Als nächstes
setzt der Prozeß 240 den
aktuellen Tokenwert um eins herauf (Schritt 247) und setzt den
aktuellen Gegenstand auf die nächste
Klasse oder Schnittstelle in der Liste (Schritt 248), bevor
er in einer Schleife zu Schritt 245 zurückkehrt. Von Schritt 245 zeichnet
der Prozeß 240 für den Fall,
daß ein
aktueller Gegenstand ein Null- bzw. Leergegenstand ist, was anzeigt,
daß keine
weiteren Klassen oder Schnittstellen in der Liste existieren, einen
Tokenwert in der Exportkomponententabelle auf (Schritt 249).
Außerdem
veröffentlicht
der Prozeß 240 die
Tokenwerte in der Exportdatei (Schritt 251) und endet dann.
-
Die 8C-1 und 8C-2 handhaben
die statischen Feld-Token, wobei 8C-2 eine
optimierte Version von 8C-1 ist,
indem Zeitkonstanten der Kompilierung inline aufgenommen werden.
Extern sichtbare statische Felder in einem Paket werden öffentlichen
Token zugewiesen. In einem Paket sichtbaren und privaten statischen
Feldern werden keine Token zugewiesen. 8C-1 beschreibt
einen Prozeß 280,
der eine Optimierung des Prozesses 250 ist. In dieser Optimierung
werden Token nicht für
endgültige
statische Felder zugeordnet, welche für Kompilierungszeitkonstanten
initialisiert werden. In diesem Fall werden die Felder nicht auf
der Karte verknüpft.
-
Gemäß 8C-1 ist ein Prozeß 250 für das Zuweisen
von statischen Feld-Token in einer öffentlichen Klasse oder Schnittstelle
dargestellt. Der Prozeß 250 erhält zunächst eine
willkürlich
geordnete Liste öffentlicher
und geschützter
statischer Felder in der öffentlichen
Klasse oder der Schnittstelle (Schritt 252). Dann setzt der
Prozeß 250 den
aktuellen Tokenwert auf Null (Schritt 254) und initialisiert
das aktuelle Feld auf das erste statische Feld in der Liste (Schritt 256).
Der Prozeß 225 stellt
dann fest, ob das aktuelle Feld Null bzw. ein Leerfeld ist, was
anzeigt, daß keine
weiteren Felder übriggeblieben
sind (Schritt 258). Falls nicht, weist der Prozeß 250 den
aktuellen Tokenwert dem aktuellen Feld zu (Schritt 260)
und setzt den aktuellen Tokenwert um eins herauf (Schritt 262).
Der Prozeß 250 setzt
dann das aktuelle Feld auf das nächste
statische Feld in der Liste (Schritt 264), bevor er in
einer Schleife zu Schritt 258 zurückkehrt.
-
Aus
Schritt 258 bestimmt der Prozeß 250 in dem Fall,
daß das
aktuelle Feld Null bzw. ein Leerfeld ist, was anzeigt, daß keine
weiteren Felder mehr vorhanden sind, ob der aktuelle Token größer als
ein vorbestimmter Wert, wie z.B. 255, ist, welches die Maximalzahl
von Token ist, die in 8-Bits dargestellt werden können (Schritt 266).
Wenn dies der Fall ist, so schlägt
der Prozeß 250 fehl
(Schritt 205). Alternativ zeichnet der Prozeß 250 die
Tokenwerte in der Exportkomponententabelle auf, wenn die Exportkomponente
erzeugt werden soll (Schritt 268). Schließlich veröffentlicht
der Prozeß 250 die
Tokenwerte in den Exportdateien (Schritt 270).
-
Gemäß der 8C-2 ist ein Prozeß 280 dargestellt,
welcher die Zuweisung von statischen Feld-Token in einer öffentlichen
Klasse oder Schnittstelle optimiert. Die Optimierung vermindert
den Speicherbedarf durch Beseitigen von Kompilierungszeitkonstanten
und durch Ersetzen von Aufrufen von Konstanten inline in dem Bytecode.
Der Prozeß 280 erhält eine
Liste öffentlicher
und geschützter
statischer Felder in einer öffentlichen Klasse
oder Schnittstelle (Schritt 282). Der Prozeß 280 setzt
dann den aktuellen Tokenwert auf Null (Schritt 284) und
initialisiert das aktuelle Feld auf das erste statische Feld in
der Liste (Schritt 286). Der Prozeß 280 überprüft dann,
ob das aktuelle Feld Null ist (keine weiteren Felder) (Schritt 288).
Falls nicht, so stellt der Prozeß 280 fest, ob das
aktuelle Feld eine Kompilierungszeitkonstante ist (Schritt 290).
Wenn dies der Fall ist, so weist der Prozeß 280 einen Wert wie
z.B. 0xFF als ein Tokenwert dem aktuellen Feld zu (Schritt 296).
Alternativ weist der Prozeß 280,
wenn das aktuelle Feld keine Kompilierungszeitkonstante ist, einen
aktuellen Tokenwert dem aktuellen Feld zu (Schritt 292)
und setzt den aktuellen Tokenwert um eins herauf (Schritt 294).
Aus den Schritten 294 und 296 setzt dann der Prozeß 280 das
aktuelle Feld auf das nächste
statische Feld in der Liste (Schritt 298), bevor er in
einer Schleife zu Schritt 288 zurückkehrt, um die Verarbeitung
der Token fortzusetzen.
-
Aus
Schritt 288 heraus überprüft der Prozeß in dem
Fall, daß ein
aktuelles Feld Null ist (keine weiteren Felder), ob das aktuelle
Token einen vorbestimmten Grenzwert, wie z.B. 255, übersteigt,
welches die Maximalzahl ist, die unter Verwendung von 8-Bits dargestellt
werden kann (Schritt 300). Wenn dies der Fall ist, so schlägt der Prozeß 280 fehl
(Schritt 205). Alternativ zeichnet der Prozeß beim Exportieren
die Tokenwerte in der Exportkomponente auf (Schritt 302).
Der Prozeß veröffentlicht
dann die Tokenwerte in der Exportdatei mit den kompilierten Zeitkonstanten
(Schritt 304), so daß das
Aufrufen der Pakete die entsprechenden Werte inline aufnehmen kann,
bevor der Prozeß endet.
-
Gemäß 8D ist
ein Prozeß 310 für das Zuweisen
statischer Methoden-Token in einer öffentlichen Klasse dargestellt.
Der Prozeß 310 erhält zunächst eine
Liste öffentlicher
und geschützter
statischer Methoden und Konstruktoren in einer öffentlichen Klasse (Schritt 312).
Der Prozeß 310 überprüft dann,
ob die Anzahl statischer Methoden einen vorbestimmten Wert, wie
z.B. 256, übersteigt
(Schritt 314). Falls nicht, so setzt der Prozeß den Tokenwert
auf Null (Schritt 316) und initialisiert die aktuelle Methode
auf die erste statische Methode in der Liste (Schritt 318).
Als nächstes überprüft der Prozeß 310,
ob die aktuelle Methode Null bzw. leer ist (keine weiteren Methoden)
(Schritt 320). Falls nicht, weist der Prozeß 310 einen
aktuellen Tokenwert der aktuellen statischen Methode zu (Schritt 322)
und setzt den aktuellen Tokenwert um eins herauf (Schritt 324).
Der Prozeß 310 setzt
dann die aktuelle Methode auf die nächste statische Methode in
der Liste (Schritt 326), bevor er in einer Schleife zu
Schritt 320 zurückkehrt.
-
Aus
Schritt 320 zeichnet der Prozeß, wenn die aktuelle Methode
Null ist (keine weiteren Methoden) den Tokenwert in der Exportkomponente
auf (Schritt 328) und veröffentlicht die Tokenwerte in
der Exportdatei (Schritt 330), bevor er endet.
-
Die 8E-1 und 8E-2 beziehen
sich auf Schemata der Zuweisung von Instanzenfeld-Token. 8E-1 zeigt einen allgemeinen Prozeß für das Zuweisen
von Feldtoken, während 8E-2 ein optimierter Prozeß ist, der Tokenzuweisungen
auf interne (oder im Paket sichtbare und private) Felder, Gruppen
und Feldtypenaufrufe erweitert und es ermöglicht, daß Token in einfacher Weise
innerhalb von Instanzen auf Offsets bzw. Verschiebungen abgebildet
werden.
-
Gemäß 8E-1 ist ein Prozeß 340 für die Zuweisung
von Instanzenfeld-Token in einer öffentlichen Klasse dargestellt.
Zunächst
erhält
der Prozeß 340 eine
Liste öffentlicher
und geschützter
Instanzenfelder in einer öffentlichen
Klasse (Schritt 342). Er überprüft dann, ob die Anzahl von
Instanzenfeldern einen vorbestimmten Wert, wie z.B. 256, übersteigt
(Schritt 344), und wenn dies der Fall ist, so schlägt er fehl
(Schritt 205). Anderenfalls setzt der Prozeß 340 den
aktuellen Tokenwert auf Null (Schritt 346) und initialisiert
ein aktuelles Feld auf das erste Feld in der Liste (Schritt 348).
Als nächstes überprüft der Prozeß 340,
ob das aktuelle Feld Null ist (Schritt 350). Falls nicht,
so weist der Prozeß 340 einen
aktuellen Tokenwert dem aktuellen Instanzenfeld zu (Schritt 352)
und setzt den aktuellen Tokenwert um eins herauf (Schritt 354).
Aus Schritt 354 setzt der Prozeß das aktuelle Feld auf das
nächste
Instanzenfeld in der Liste (Schritt 360), bevor er in einer
Schleife zurückkehrt
zu Schritt 350. Aus Schritt 350 veröffentlicht
der Prozeß 340 in
dem Fall, daß das
aktuelle Feld Null ist, die Tokenwerte in der Exportdatei (Schritt 362)
und endet dann.
-
Verschiedene
Faktoren können
bei der Optimierung des generellen Ansatzes nach 8E-1 in Betracht gezogen werden. Generell bleibt
die Anordnung der Token flexibel, so daß die Tokenanordnung an spezielle
Implementierungen angepaßt
werden kann. 8E-2 beschreibt ein eingeschränktes Zuordnungsschema,
wie es in dem nachstehenden Beispiel dargestellt ist:
-
-
Gemäß 8E-2 ist ein Prozeß 370 für die Optimierung
der obigen Zuweisung von Instanzenfeldtoken dargestellt. Wie zuvor
erhält
der Prozeß 370 eine
Liste aller Instanzenfelder in einer Klasse (Schritt 372). Als
nächstes überprüft der Prozeß 370,
ob die numerierten Instanzenfelder einen vorbestimmten Wert, wie
z. B. 256, übersteigen
(Schritt 374). Wenn dies der Fall ist, so schlägt der Prozeß fehl (Schritt 205)
und falls nicht, so sortiert der Prozeß 370 die Liste nach
Kategorien einschließlich öffentlicher
und geschützter
ursprünglicher Typen
als erstes, öffentlicher
und geschützter
Aufruftypen als zweites, Paket- und privater Aufruftypen als drittes
und Paket- und privater ursprünglicher
Typen als letztes (Schritt 376). Der Tokenwert wird auf
null gesetzt (Schritt 378) und das aktuelle Feld wird auf
das erste Instanzenfeld in der Liste initialisiert (Schritt 380).
Als nächstes überprüft der Prozeß 370,
ob das aktuelle Feld null ist (Schritt 382). Falls nicht,
weist der Prozeß dem aktuellen
Feld einen aktuellen Tokenwert zu (Schritt 384) und setzt
den aktuellen Tokenwert um 1 herauf (Schritt 386). Dann
bestimmt der Prozeß 370,
ob das aktuelle Feld von einem unversehrten bzw. ganzzahligen Typ
ist (Schritt 388). Der ganzzahlige Typ benötigt zwei
Slots, um zu ermöglichen,
daß Token
in einfacher Weise auf Instanzen abgebildet bzw. diesen zugeordnet
werden. Wenn dies der Fall ist, wird der aktuelle Tokenwert um 1
heraufgesetzt (Schritt 390). Aus Schritt 388 oder
Schritt 390 setzt der Prozeß 370 das aktuelle
Feld auf das nächste
Instanzenfeld in der Liste (Schritt 392), bevor er in einer
Schleife zurückkehrt
zu Schritt 382.
-
Aus
Schritt 382 veröffentlicht
der Prozeß 370,
wenn das aktuelle Feld null ist, die Tokenwerte der öffentlichen
und geschützten
Instanzenfelder in der Exportdatei (Schritt 394) bevor
er endet.
-
Die 8F-1 und 8F-2 weisen
für virtuelle
Methoden Token zu. 8F-1 zeigt ein allgemeines Schema
für die
Zuordnung von virtuellen Methodentoken, während 8F-2 die
Tokenzuweisung auf paketsichtbare virtuelle Methoden erweitert.
-
Gemäß den 8F-1 und 8F-2 sind
Prozesse für
die Zuweisung virtueller Methodentoken dargestellt. Allgemein werden
virtuellen Methoden, die in einem Paket definiert werden, entweder
exportierbare oder interne Token zugeordnet. Exportierbare Token
werden öffentlichen
und geschützten
virtuellen Methoden zugewiesen; in diesem Fall ist das höchstwertige
Bit des Token null. Interne Token werden paketsichtbaren virtuellen
Methoden zugewiesen; in diesem Fall ist das höchstwertige Bit des Token eins.
Da das höchstwertige Bit
reserviert ist, haben diese Token einen Bereich von null bis einschließlich 127.
-
Exportierbare
Token für
extern sichtbare, eingeführte
virtuelle Methoden in einer Klasse sind der Reihe nach numeriert,
beginnend mit einem um eins größeren Wert
als das höchste
numerierte exportierbare Methodentoken der Superklasse dieser Klasse.
Wenn eine Methode eine in der Superklasse der Klasse implementierte
Methode überlagert
bzw. außer
Kraft setzt, verwendet diese Methode dieselbe Tokennummer wie die
entsprechende Methode in der Superklasse, so daß übergagerte bzw. außer Kraft
gesetzte Methoden so gekennzeichnet werden können, als ob sie sich auf die
Methode beziehen, welche sie außer
Kraft gesetzt haben.
-
Interne
virtuelle Methodentoken werden von exportierbaren virtuellen Methodentoken
auf unterschiedliche Weise zugewiesen. Wenn eine Klasse und ihre
Superklasse in demselben Paket definiert werden, werden die Token
für die
paketsichtbaren, eingeführten
virtuellen Methoden in dieser Klasse der Reihe nach numeriert, beginnend
bei einem um eins größeren Wert
als das höchste
numerierte interne virtuelle Methodentoken der Superklasse dieser
Klasse. Wenn die Klasse und ihre Superklasse in unterschiedlichen
Paketen definiert sind, werden die Token für die paketsichtbaren, eingeführten virtuellen
Methoden in dieser Klasse, beginnend bei Null, der Reihe nach numeriert.
Wenn eine Methode eine in der Superklasse der Klasse implementierte
Methode außer
Kraft setzt bzw. deren Stelle einnimmt, verwendet diese Methode
dieselbe Tokennummer wie die entsprechende Methode in der Superklasse.
Als Hintergrundinformation spezifiziert die Definition der Java-Programmiersprache,
daß das
Außerkraftsetzen
einer paketsichtbaren virtuellen Methode nur dann möglich ist,
wenn sowohl die Klasse als auch ihre Superklasse in demselben Paket
definiert sind. Das hohe bzw. höchstwertige
Bit des Bytes, welches ein virtuelles Methodentoken enthält, wird
immer auf eins gesetzt, um anzuzeigen, daß es ein internes Token ist.
Die Reihenfolge der virtuellen Methodentoken des eingeführten Paketes
in einer Klasse ist nicht festgelegt.
-
In 8F-1 erhält
der Prozeß 400 zunächst eine
Liste öffentlicher
und geschützter
virtueller Methoden in einer Klasse (Schritt 402). Der
Prozeß 400 überprüft dann,
ob die Klasse eine Superklasse hat (Schritt 404). Wenn
dies der Fall ist, so überprüft der Prozeß 400 weiterhin,
ob die Superklasse sich in demselben Paket befindet (Schritt 406).
Aus Schritt 406 findet der Prozeß, für den Fall, daß die Superklasse
in demselben Paket ist, die Superklasse (Schritt 408) und
erhält
die virtuellen Methoden und Token der Superklasse (Schritt 412). Der
Satz von virtuellen Methoden umfaßt diejenigen, die alle Superklassen
der (Super?)klasse definieren. Aus Schritt 406 findet der
Prozeß 400 für den Fall,
daß die
Superklasse nicht in demselben Paket ist, die Superklasse in der
Exportdatei des importierten Paketes (Schritt 410) und
geht dann weiter zu Schritt 412. Aus Schritt 412 initialisiert
der Prozeß 400 einen
aktuellen Tokenwert auf den des maximalen virtuellen Methodentoken
der Superklasse und setzt seinen Schritt um eins herauf (Schritt 414),
was sicherstellt, daß es
innerhalb der Hierarchie keine Tokenkollisionen gibt.
-
Aus
Schritt 404 initialisiert der Prozeß 400 für den Fall,
daß die
Klasse keine Superklasse hat, den aktuellen Tokenwert auf null (Schritt 416).
Aus Schritt 414 oder Schritt 416 initialisiert
der Prozeß 400 die
aktuelle Methode auf die erste virtuelle Methode in der Liste (Schritt 418).
Als nächstes
stellt der Prozeß 400 fest,
ob die aktuelle Methode eine Null-Methode ist (Schritt 420).
Falls nicht, so stellt der Prozeß fest, ob die aktuelle virtuelle
Methode durch die Superklasse definiert ist (Schritt 422).
Wenn dies der Fall ist, ist die Methode eine Übernahmemethode und es wird
derselbe Token der aktuellen Methode zugewiesen, wie er der übernommenen
bzw. außer
Kraft gesetzten Methode in der Superklasse zugewiesen worden war
(Schritt 424), bevor der Prozeß in einer Schleife zurückgeht zu
Schritt 420.
-
Aus
Schritt 422 ergibt sich, daß in dem Fall, daß die aktuelle
virtuelle Methode nicht durch die Superklasse definiert ist, sie
dann eine eingeführte
Methode ist. In diesem Fall weist der Prozeß 400 der aktuellen Methode
einen aktuellen Tokenwert zu (Schritt 422) und setzt den
aktuellen Tokenwert um eins herauf (Schritt 428). Der Prozeß 400 setzt
dann die aktuelle Methode auf die nächste Methode in der Liste
(Schritt 430), bevor er in einer Schleife zurückgeht zu
Schritt 420. Aus Schritt 420 überprüft der Prozeß 400,
für den
Fall, daß die aktuelle
Methode null bzw. leer ist, ob der aktuelle Tokenwert einen vorbestimmten
Wert, wie z. B. 127, übersteigt
(Schritt 432). Wenn dies der Fall ist, so schlägt der Prozeß 400 fehl
(Schritt 205). Alternativ veröffentlicht der Prozeß 400,
wenn der Tokenwert nicht größer als
127 ist, die Tokenwerte in der Exportdatei zusammen mit den übernommenen
bzw. ererbten Methoden und deren Tokenwerten (Schritt 434),
bevor er beendet wird. Der Prozeß nach 8F-1 kann
auch verwendet werden für
die Zuweisung von Token zu öffentlichen
und geschützten
Methoden in einer paketsichtbaren Klasse, wie sie in 8F-2 dargestellt ist.
-
In 8F-2 ist ein Prozeß 440 für die Erweiterung
der Tokenzuordnung zu paketsichtbaren virtuellen Methoden in einer
Klasse dargestellt. Der Prozeß 440 enthält zunächst eine
Liste von paketsichtbaren virtuellen Methoden in der Klasse (Schritt 442).
Als nächstes überprüft er, ob
die Klasse eine Superklasse hat (Schritt 444). Wenn dies
der Fall ist, so überprüft der Prozeß weiterhin,
ob die Superklasse sich in demselben Paket befindet (Schritt 446).
Wenn dies der Fall ist, so findet der Prozeß 440 eine Superklasse
in demselben Paket (448), erhält die paketsichtbaren virtuellen
Methoden und Token der Superklasse (Schritt 450) und initialisiert den
aktuellen Tokenwert auf den maximalen Wert der virtuellen Methodentoken
der Superklasse plus eins (Schritt 452), um Tokenkollisionen
innerhalb der Hierarchie zu vermeiden, die durch das Paket gegeben
ist. Dies stellt sicher, daß Tokenwerte,
welche zuvor innerhalb von Superklassen zugeordnet waren, für eingeführte Methoden
nicht erneut verwendet werden. Es versteht sich, daß Schritt 450 bis
herauf zu den Superklassen in demselben Paket rekursiv sein kann.
-
Aus
Schritt 444, für
den Fall, daß eine
Klasse keine Superklasse hat, oder aus Schritt 446, für den Fall, daß die Superklasse
sich nicht in demselben Paket befindet, setzt der Prozeß 440 den
aktuellen Tokenwert auf null (Schritt 454). Insbesondere
dann, wenn die Superklasse sich nicht in demselben Paket befindet,
sind paketsichtbare virtuelle Methoden dieser Superklasse nicht
zugänglich
und damit in Schritt 454 nicht enthalten. Diese potentiellen
Methoden werden berücksichtigt,
wenn Aufrufe von virtuellen Methoden aufgelöst werden, wie es im folgenden
noch im Zusammenhang mit den 9D-2 und 9D-3 beschrieben wird.
-
Aus
Schritt 452 oder Schritt 454 initialisiert der
Prozeß 440 die
aktuelle Methode auf die erste virtuelle Methode in einer Liste
(Schritt 456). Als nächstes überprüft der Prozeß 440,
ob die aktuelle Methode null bzw. leer ist (Schritt 458).
Falls nicht, so überprüft der Prozeß 440,
ob die aktuelle virtuelle Methode durch eine Superklasse definiert
ist (Schritt 460). In diesem Fall ist die Methode eine Übernahmemethode.
Wenn dies der Fall ist, ordnet der Prozeß 440 denselben Tokenwert
der aktuellen Methode zu, so wie er der übernommenen (außer Kraft
gesetzten) Methode in der Superklasse zugeordnet war (Schritt 462),
bevor er in einer Schleife zu Schritt 458 zurückkehrt.
-
Aus
Schritt 460 ergibt sich, daß dann, wenn die aktuelle virtuelle
Methode nicht durch ihre Superklasse definiert ist, sie eine eingeführte Methode
ist. In diesem Fall ordnet der Prozeß 440 einen aktuellen
Tokenwert der aktuellen Methode zu und setzt das hohe Bit auf eins
(Schritt 464). Das hohe Bit des virtuellen Methodentoken
wird verwendet, um zu bestimmen, ob es sich um ein öffentliches
oder um ein privates virtuelles Methodentoken handelt. Als nächstes setzt
der Prozeß 440 den
aktuellen Tokenwert um eines herauf (Schritt 466) und setzt
die aktuelle Methode auf die nächste
Methode in der Liste (Schritt 468), bevor er in einer Schleife zurückkehrt
zu Schritt 458.
-
In
Schritt 458 bestimmt der Prozeß in dem Fall, daß die aktuelle
Methode eine Null-Methode ist, ob der aktuelle Tokenwert einen Wert,
wie z. B. 127 überschreitet
(welches die maximale Anzahl ist, die mit acht Bits darstellbar
ist, wenn das hohe Bit reserviert ist), und zwar in Schritt 470.
Wenn dies der Fall ist, so schlägt
der Prozeß 440 fehl
(Schritt 205). Anderenfalls endet der Prozeß 440 in
dem Fall, daß der
aktuelle Tokenwert innerhalb des Bereiches liegt. Man beachte, daß Token
für paketsichtbare
Methoden intern verwendet werden und nicht exportiert werden.
-
Virtuelle
Methodenaufrufe können
nur während
der Ausführung
aufgelöst
werden. Die virtuelle Methodentabelle erlaubt es der Karte zu bestimmen,
welche Methode aufgerufen werden soll, und zwar auf der Basis des
Token ebenso wie der Instanzen der Klasse der Methode. Der Tokenwert
wird als ein Index für
die virtuelle Methodentabelle verwendet. 8G-1 zeigt
einen Prozeß 480 für den Aufbau öffentlicher
virtueller Methodentabellen in einer Klasse. Als erstes erhält man eine
Liste und geschützte
virtuelle Methoden in der Klasse (Schritt 482). Als nächstes erhält der Prozeß 480 virtuelle
Methoden und Token einer Superklasse (Schritt 484). Schritt 484 ist
rekursiv und schließt
alle Superklassen der Klasse ein. Der Prozeß 480 erzeugt dann
eine Tabelle, ordnet virtuelle Methoden nach Tokenwerten (Schritt 486)
und beseitigt Duplikate von virtuellen Methoden. Duplikate werden
für übernommene
(bzw. überschriebene
oder außer
Kraft gesetzte) Methoden erzeugt. In diesem Fall wird die in der
aktuellen Klasse definierte Methode anstelle der in einer Superklasse
definierten in der Methodentabelle wiedergegeben. Der Prozeß 480 setzt
dann eine Zahl auf einen maximalen virtuellen Methodentokenwert
in Schritt 488 und zeichnet eine Tabelle und die Zahl in
der Klassenkomponente auf (Schritt 490) bevor er endet.
-
Gemäß 8G-2 ist ein Prozeß 500 dargestellt,
welcher den Aufbau öffentlicher
virtueller Methodentabellen in der Klasse optimiert. Der Prozeß 500 senkt
die Größe herab,
die für
das Speichern einer virtuellen Methodentabelle erforderlich ist,
indem er überlappende
Elemente in einer virtuellen Methodentabelle einer Superklasse entfernt.
-
Der
Prozeß 500 erhält zunächst eine
Liste öffentlicher
und geschützter
virtueller Methoden in einer Klasse (Schritt 502). Als
nächstes
erhält
er die virtuellen Methoden und Token der Superklasse (Schritt 504). Schritt 504 ist
rekursiv und umfaßt
alle Superklassen der Klasse. Als nächstes initialisiert der Prozeß 500 eine Tabelle
durch Ordnen der virtuellen Methoden, die in den Schritten 502 und 504 erhalten
wurden, nach Tokenwerten (Schritt 506). Dieser Prozeß geht von
der Annahme aus, daß der
Prozeß bzw.
die Tabelle zumindest einen Eintrag hat. Der Prozeß initialisiert
dann eine Zahl auf einen maximalen virtuellen Methodentoken plus eins
(Schritt 508). Der Prozeß 500 setzt auch eine
Basiszahl auf null (Schritt 510). Als nächstes überprüft der Prozeß 500,
ob die Zahl positiv ist (Schritt 512). Wenn dies der Fall
ist, so überprüft der Prozeß, ob der
erste Eintrag in der Tabelle durch die aktuelle Klasse definiert
ist (Schritt 514). Falls nicht, entfernt der Prozeß die Methode
aus der Tabelle und verschiebt die verbleibenden Methoden in der
Tabelle nach oben (Schritt 518). Der Prozeß 500 zählt dann
die Zahl um eins herab (Schritt 520) und setzt die Basiszahl
um eins herauf (Schritt 522), bevor er in einer Schleife
zurückkehrt
zu Schritt 512.
-
Aus
Schritt 514 geht der Prozeß 500 für den Fall,
daß der
erste Eintrag in der aktuellen Klasse definiert ist oder für den Fall,
daß die
Zahl in Schritt 512 null ist, weiter, um die Tabelle, die
Zahl und die Basis in der Klassenkomponente aufzuzeichnen (Schritt 516)
bevor er endet.
-
Die 8H-1 und 8H-2 zeigen
einen Prozeß 524 für das Zuweisen
von Schnittstellenmethodentoken in einer öffentlichen Schnittstelle.
Insbesondere 8H-2 zeigt genauer den Schritt 526 nach 8H-1.
-
Gemäß 8H-1 weist der Prozeß 524 Schnittstellenmethodentoken
in einer öffentlichen
Schnittstelle zu. Der Prozeß 524 erhält anfänglich einen
Satz von Schnittstellen- bzw. Interface-Methoden in der öffentlichen Schnittstelle (Schritt 525).
Als nächstes
erhält
der Prozeß 524 eine
Liste von Superschnittstellen bzw. Super-Interfaces der Schnittstelle
bzw. des Interfaces (Schritt 526). Diese Operation wird
genauer in 8H-2 definiert. Der Prozeß 524 verschmilzt
dann den Satz von Methoden, der durch die Schnittstelle und ihre
Superschnittstellen definiert wird (Schritt 527). Als nächstes überprüft der Prozeß 524,
ob mehr als 256 Methoden existieren oder nicht (Schritt 529).
Wenn dies der Fall ist, so schlägt
der Prozeß 524 fehl
(Schritt 205). Ansonsten setzt der Prozeß 524,
wenn weniger als 256 Methoden existieren, den aktuellen Tokenwert
auf null (Schritt 530) und initialisiert die aktuelle Methode
auf die erste Methode in dem Satz von Methoden (Schritt 532).
Als nächstes überprüft der Prozeß 524,
ob die aktuelle Methode null (Leermethode) ist (Schritt 533).
Falls nicht, so weist der Prozeß 524 den
aktuellen Tokenwert der aktuellen Schnittstellenmethode zu (Schritt 534),
setzt den Tokenwert um eins herauf (Schritt 535) und setzt
die aktuelle Methode als die nächste
Methode in dem Satz (Schritt 536), bevor sie in einer Schleife
zurückkehrt
zu Schritt 533).
-
Aus
Schritt 533 veröffentlicht
der Prozeß 524,
wenn die aktuelle Methode null ist, die Superschnittstellenliste,
die zu der Schnittstelle gehört
und die Methodentokenwerte in der Exportdatei (Schritt 537)
und endet.
-
Gemäß 8H-2, ist der Schritt 526 aus 8H-1 genauer dargestellt. Zunähst wählt der Prozeß nach 8H-2 eine Schnittstelle (ein Interface) aus (Schritt 682).
Als nächstes
erhält
er eine Liste von Schnittstellen, die durch die Schnittstelle übernommen
(vererbt) wurden (Schritt 684) und setzt die aktuelle Schnittstelle
auf die erste Schnittstelle in der Liste (Schritt 686).
Als nächstes
initialisiert der Prozeß nach 8H-2 den Ergebnissatz auf einen Leersatz (Schritt 688).
Aus Schritt 688 addiert der Prozeß nach 8H-2 iterativ Schnittstellen
zu einem Ergebnissatz. Dies geschieht zunächst durch Überprüfen, ob die aktuelle Schnittstelle null
bzw. eine Leerschnittstelle ist, was anzeigt, daß keine anderen Schnittstellen
verarbeitet werden müssen (Schritt 690).
Wenn das nicht der Fall ist, dann erhält der Prozeß einen
Satz von Superschnittstellen der aktuellen Schnittstelle (692).
Schritt 692 ruft den Prozeß 526 rekursiv auf.
-
Nach
dem Abschluß von 692 addiert
der Prozeß nach 8H-2 den Satz von Superschnittstellen zu einem
Ergebnissatz (Schritt 694) und die aktuelle Schnittstelle
zu dem Ergebnissatz (Schritt 696). Der Prozeß setzt
dann die aktuelle Schnittstelle auf die nächste Schnittstelle (Schritt 698)
und kehrt in einer Schleife zurück zu
Schritt 690, um die Verarbeitung aller Schnittstellen fortzusetzen.
Aus Schritt 690 endet der Prozeß nach 8H-2 für den Fall,
daß die
aktuelle Schnittstelle null ist, durch Liefern des Ergebnissatzes.
-
Eine
Schnittstellentabelle enthält
einen Eintrag für
jede Schnittstelle, welche direkt durch eine Klasse implementiert
ist und für
alle Superschnittstellen der direkt implementierten Schnittstellen.
Jeder Eintrag in der Schnittstellentabelle enthält eine Identifikation der
Schnittstelle und eine Schnittstellenmethodentabelle. Die Tabelle
bildet Schnittstellenmethodenerklärungen auf Implementierungen
in der Klasse ab. 8I-1 und 8I-2 zeigen
einen Prozeß 700 für den Aufbau
einer Schnittstellentabelle einer Klasse. Insbesondere zeigt eine 8I-2 die Schritte 708 nach 8I-1 in genaueren Einzelheiten.
-
Gemäß 8I-1 ist ein Prozeß 700 für den Aufbau
von Interface-Tabellen dargestellt. Zunächst erhält der Prozeß 700 eine
Liste von Schnittstellen, einschließlich Superschnittstellen (siehe
Prozeß 526),
die durch die aktuelle Klasse implementiert sind (Schritt 702).
Als nächstes
setzt der Prozeß 700 die
aktuelle Schnittstelle auf die erste Schnittstelle in diesem Satz
(Schritt 704). Der Prozeß 700 überprüft dann,
ob die aktuelle Schnittstelle null ist, was anzeigt, daß sie beendet
ist (Schritt 706). Falls nicht, so geht der Prozeß 700 weiter,
um eine Schnittstellenmethodentabelle für die aktuelle Schnittstelle
für die
Klasse aufzubauen (Schritt 708), wie es genauer in 8I-2 dargestellt ist. Als nächstes setzt der Prozeß 700 eine
aktuelle Schnittstelle auf die nächste Schnittstelle
(Schritt 710), bevor er in einer Schleife zurückkehrt
zu Schritt 706. Aus Schritt 706 zeichnet der Prozeß 700 für den Fall,
daß die
aktuelle Schnittstelle null ist, die Schnittstellen mit ihren Schnittstellenmethodentabellen
in der Klassenkomponente auf (Schritt 712), bevor er endet.
-
Gemäß 8I-2 ist der Schritt 708 genauer dargestellt.
Dieser Prozeß erhält zunächst die
virtuelle Methodentabelle für
die Klasse (Schritt 722) und die Schnittstellenmethoden
und Token für
die Schnittstelle, einschließlich
der übernommenen
bzw. ererbten Methoden (Schritt 724). Als nächstes initialisiert
der Prozeß nach 8I-2 eine Schnittstellenmethodentabelle durch
Ordnen der Methoden nach ihrem Tokenwert (Schritt 726).
Als nächstes
setzt der Prozeß die
aktuelle Methode auf die erste Methode der Schnittstellenmethodentabelle
(Schritt 728). Aus Schritt 728 überprüft der Prozeß, ob die
aktuelle Methode null ist, was anzeigt, daß sie beendet ist (Schritt 730). Falls
nicht, so findet der Prozeß nach 8I-2 eine Implementierung der Schnittstellenmethode
in der virtuellen Methodentabelle (732). Als nächstes zeichnet
der Prozeß einen
Tokenwert der virtuellen Methode in der Schnittstellenmethodentabelle
an der Position der aktuellen Methode auf (Schritt 734).
Er setzt dann die aktuelle Methode auf die nächste Methode der aktuellen
Schnittstelle (Schritt 736), bevor er in einer Schleife
zurückkehrt
zu Schritt 730. Aus Schritt 730 endet der Prozeß nach 8I-2, falls die aktuelle Methode null ist.
-
Die
dynamische Verbindung bzw. Verknüpfung
von Elementen während
der Ausführung
wird als nächstes
in den 9A–9C erläutert, welche
die Auflösung
von Aufrufen von dynamischen Elementen beschreiben. Während der
Kompilierung, Konversion und Tokenzuweisung können Aufrufe von Instanzenfeldern,
virtuellen Methoden und Schnittstellenmethoden nicht zu einer bestimmten
Implementierung aufgelöst werden,
sondern nur zu einer abstrakten Beschreibung des Gegenstandes.
-
Im
Falle von Instanzenfeldern werden Token innerhalb des Umfangs der
definierenden Klasse zugewiesen. Eine Instanz der Klasse enthält alle
Felder, die nicht nur durch die Klasse, sondern durch alle ihre
Superklassen definiert sind. Die Token zeigen die Position des Feldes
innerhalb der Instanzen nicht an, da sie ein bestimmtes Layout der
Instanz nicht wiedergeben können
und die Anordnung von privaten und paketsichtbaren Feldern, welche
durch die Superklasse definiert werden, nicht berücksichtigen
können.
-
Im
Falle virtueller Methoden sind während
der Kompilierung und Konversion der Name und die Typsignatur bekannt,
ebenso wie eine Klasse innerhalb einer Hierarchie, die eine solche
Methode implementiert. Die genaue Implementierung kann jedoch bis
zur Ausführung
nicht bekannt sein, und es dann möglich ist, die betreffende
Klasse der Instanz, auf welcher die Methode aufgerufen wird, zu
bestimmen. Beispielsweise implementieren sowohl eine Klasse A als
auch ihre Superklasse B eine Methodendefinition M. Es bleibt bis
zur Ausführung
unbekannt, ob ein Aufruf der Methode M auf einer Instanz der Kompilierungszeit
vom Typ B zu einer Ausführung
der Implementierung der Klasse A oder der Klasse B führt.
-
Um
eine Einrichtung bereitzustellen, die in passender Weise einen Aufruf
einer virtuellen Methode während
der Ausführung
anordnet, wird eine Zuweisung eines virtuellen Methodentoken innerhalb
einer Klassenhierarchie untersucht (scoped). D.h., eine Methode
einer Unterklasse, welche eine Methode außer Kraft setzt, die zuvor
in einer Superklassenerbkette eingeführt wurde, muß denselben
Tokenwert haben, wie die Methode, die sie übernimmt bzw. außer Kraft
setzt. Weiterhin müssen
eingeführte
Methoden (diejenigen Methoden, die in einer Superklasse definierte
Methoden nicht übernehmen
bzw. außer
Kraft setzen) Tokenwerte haben, die innerhalb der Erbfolge eindeutig
sind. Virtuelle Methodentabellen werden für jede Klasse definiert, um eine
Einrichtung für
die Zuordnung eines virtuellen Methodentoken für eine bestimmte Implementierung
bereitzustellen.
-
Schnittstellenmethoden
sind ähnlich
wie virtuelle Methoden insofern, als die betreffende Implementierung
bis zur Ausführungszeit
unbekannt bleibt, sie unterscheiden sich jedoch dadurch, daß Schnittstellenmethoden
von mehreren Schnittstellen vererbt werden können. Eine Mehrfach-Vererbung von Schnittstellen
verursacht ein Problem hinsichtlich der Art, wie virtuelle Methodentoken
zugewiesen werden. Eine Methode in einer Klasse, die eine Methode
außer
Kraft setzt, welche in mehr als einer Schnittstelle eingeführt wurde,
kann notwendigerweise nicht denselben Tokenwert haben, wie (alle)
die Methoden, die sie außer
Kraft setzt, da die mehrfachen Definitionen allesamt unterschiedliche
Werte haben können.
Daher werden jedem Satz von Methoden für eine bestimmte Schnittstelle
Tokenwerte zugewiesen, ohne Berücksichtigung
der Tokenwerte der Methoden irgendeiner anderen Schnittstelle.
-
Da
Schnittstellen Tokenwerte nicht gemeinsam verwenden, ist zusätzliche
Information erforderlich, um den Aufruf einer Schnittstellenmethode
in eine bestimmte Methodenimplementierung umzusetzen. Da Schnittstellenmethodentoken
innerhalb des Umfangs einer Schnittstelle eindeutig sind, werden
sowohl das Schnittstellenmethodentoken als auch die Identität der Schnittstelle
benötigt,
um die durch die Klasse einer Instanz zur Ausführungszeit implementierte Methode
zu bestimmen. Eine Schnittstellentabelle wird für jede Klasse definiert, welche
eine Schnittstellenidentität
auf einer Schnittstellenmethodentabelle abbildet. Die Schnittstellenmethodentabelle
bildet die Schnittstellenmethodentoken für diese Schnittstelle auf Methodenimplementierung in
dieser Klasse ab bzw. ordnet sie einander zu.
-
Die 9A–9C sind
Flußdiagramme,
welche Prozesse zum Auflösen
von Token während
der Ausführung
veranschaulichen. Gemäß 9A ist
ein Prozeß 580 für das Auflösen von
Instanzenfeldaufrufen dargestellt. Zunächst erhält der Prozeß 580 eine
Instanz, die das Feld enthält,
von einem Laufzeitstapel (Schritt 582). Als nächstes bestimmt
der Prozeß 580 ein
Token, welches zu dem Feld gehört
und ordnet das Token einem Index zu (Schritt 584). Das
Zuordnen bzw. Abbilden des Token auf den Index kann eine Untersuchung der
Typinformation des Instanzenfeldes erfordern. Darüber hinaus
kann der Vorgang das Einstellen des Tokenwerts durch die Größe der Instanz
der Superklasse erfordern. Schließlich findet der Prozeß 580 die
Darstellung bzw. Repräsentation
des Feldes in der Instanz unter Verwendung des Index (Schritt 586),
bevor er endet.
-
In 9B-1 ist ein Prozeß 620 für das Auflösen eines
Aufrufs von öffentlichen
oder geschützten
virtuellen Methoden dargestellt. Zunächst erhält der Prozeß 620 eine
Instanz einer Klasse von dem Laufzeitstapel (Schritt 621)
und bestimmt die Klasse der Instanz (Schritt 622). Als
nächstes
greift der Prozeß 620 auf
die Tabelle der öffentlichen
virtuellen Methode der Klasse zu (Schritt 624) und erhält einen
Methodentabelleneintrag unter Verwendung des Methodentoken als ein
Index (Schritt 626). Schließlich findet der Prozeß 620 die
Methode auf der Basis des Inhalts des Eintrags in der virtuellen
Methodentabelle, führt
diese aus (Schritt 628) und endet.
-
Gemäß 9B-2 ist ein Prozeß 600 zum Auflösen eines
Aufrufs irgendeiner virtuellen Methode (einschließlich von
paketsichtbaren) dargestellt. Zuerst erhält der Prozeß 600 eine
Instanz einer Klasse aus dem Laufzeitstapel (Schritt 601)
und bestimmt die Klasse der Instanz (Schritt 602). Als
nächstes
bestimmt der Prozeß 600,
ob das hohe Bit des Methodentoken auf eins gesetzt ist (Schritt 604).
Falls nicht, holt sich der Prozeß 600 eine öffentliche
virtuelle Methodentabelle (Schritt 606) und verwendet das
Methodentoken als einen Index in der virtuellen Methodentabelle
(Schritt 608). Aus Schritt 604 setzt der Prozeß 600 für den Fall,
daß das
hohe Bit des Methodentoken gleich eins ist, dann das hohe Bit auf
null (Schritt 610) und erhält die virtuelle Paketmethodentabelle (Schritt 612),
bevor sie zu Schritt 608 weitergeht. Schließlich findet
der Prozeß 600 die
Methode auf der Basis des Inhaltes des Eintrages in der virtuellen
Methodentabelle und führt
sie aus (Schritt 614) und endet.
-
9B-3 zeigt einen optimierten Prozeß 670 für das Auflösen eines
Aufrufs irgendeiner virtuellen Methode unter Verwendung optimierter
virtueller Methodentabellen, wie es zu 8G-2 beschrieben
wurden. Zunächst
erhält
der Prozeß 670 eine
Instanz einer Klasse aus dem Laufzeitstapel (Schritt 671)
und setzt die aktuelle Klasse als die Klasse der Instanz ein (Schritt 672).
Ein Methodentabellenindex wird initialisiert auf den Methodentokenwert
(Schritt 674). Der Prozeß 670 stellt dann
fest, ob das hohe Bit des Methodentoken gleich eins ist (Schritt 676).
Falls nicht, so setzt der Prozeß 670 einen
Basiswert auf die Basis der öffentlichen
Methodentabelle der aktuellen Klasse (Schritt 678). Als
nächstes
wird die Methodentabelle auf die öffentliche virtuelle Methodentabelle
der aktuellen Klasse gesetzt (Schritt 680). Der Prozeß 670 überprüft dann,
ob der Methodentabellenindex kleiner ist als der Basiswert (Schritt 682)
und wenn dies der Fall ist, so setzt er die aktuelle Klasse als
die Superklasse der aktuellen Klasse ein (Schritt 684).
Aus Schritt 684 geht der Prozeß 670 in einer Schleife zurück zu Schritt 676,
um die Verarbeitung weiter durchzuführen. Wenn in Schritt 676 das
hohe Bit gleich eins ist, so setzt der Prozeß 670 das hohe Bit
des Methodentabellenindex auf null (Schritt 690). Er setzt
den Basiswert auf die Basis der Paketmethodentabelle der aktuellen
Klasse (Schritt 692) und setzt die Methodentabelle auf
die virtuelle Paketmethodentabelle der aktuellen Klasse (Schritt 694),
bevor er zu Schritt 682 weitergeht.
-
Aus
Schritt 682 erhält
der Prozeß 670,
wenn der Methodentabellenindex größer als die Basis ist, einen Methodentabelleneintrag
unter Verwendung des Methodentabellenindex plus des Basiswertes
(Schritt 686). Der Prozeß 670 findet dann
die Methode auf der Basis des Inhaltes des Eintrages in der Methodentabelle
der aktuellen Klasse (Schritt 688). Danach endet der Prozeß 670.
-
Gemäß 9C ist
ein Prozeß 650 für das Auflösen von
Schnittstellenmethodenaufrufen dargestellt. Zunächst erhält der Prozeß 650 eine
Instanz einer Klasse aus dem Laufzeitstapel (Schritt 651)
und setzt die aktuelle Klasse auf die Klasse der Instanz (Schritt 652).
Als nächstes
sucht der Prozeß 650 nach
der angegebenen Schnittstelle in der Schnittstellentabelle der aktuellen
Klasse (Schritt 654). Der Prozeß bestimmt dann, ob die Schnittstelle
gefunden wurde (Schritt 656). Falls nicht, setzt der Prozeß dann die
aktuelle Klasse auf die Superklasse der aktuellen Klasse (Schritt 660),
bevor er in einer Schleife zurückkehrt
zu Schritt 654.
-
Aus
Schritt 656 erhält
der Prozeß 650 für den Fall,
daß die
angegebene Schnittstelle gefunden wurde, die entsprechende Schnittstellenmethodentabelle
in der aktuellen Klasse (Schritt 662). Er enthält dann
das virtuelle Methodentoken aus dem Eintrag in der Tabelle, deren
Index gleich dem Schnittstellenmethodentoken ist (Schritt 664).
Der Prozeß 650 erhält dann
die öffentliche
virtuelle Methodentabelle der Klasse der Instanz (Schritt 666).
Der Prozeß 650 erhält die Position
der virtuellen Methode von dem Eintrag in der Tabelle, der zu dem
virtuellen Methodentoken gehört
(Schritt 668). Der Prozeß 650 lokalisiert
dann die Methode auf der Basis des Inhaltes des Eintrags in der
virtuellen Methodentabelle (Schritt 669). Wenn dies geschehen
ist, endet der Prozeß 650.
-
Auch
wenn die Erfindung unter Bezug auf eine Smart Card-Implementierung
erläutert
wurde, findet die Erfindung Anwendungen auch auf andere Einrichtungen
mit kleiner Basis, wie z. B. Einrichtungen, die in ihrem Speicher
oder auch in ihrer Rechnerleistung oder -geschwindigkeit relativ
beschränkt
oder begrenzt sind. Derartige ressourcenbeschränkte Einrichtungen können Umfangs- bzw. Grenzpfadabtasteinrichtungen,
feldprogrammierbare Einrichtungen, Pager und Mobiltelefone und vieles
andere sein. Die Erfindung kann sich als vorteilhaft erweisen, wenn
man „Servlets" verwendet, wenn
diese eine gemeinsame Verwendung von Objekten haben. Gewisse Desktop-Systeme können ebenfalls
die Techniken der vorliegenden Erfindung ausnutzen.
-
Die
vorliegende Erfindung bezieht sich auch auf eine Vorrichtung zum
Durchführen
dieser Vorgänge. Diese
Vorrichtung kann speziell für
den geforderten Zweck aufgebaut werden oder sie kann einen üblichen Vielzweckcomputer
aufweisen, der durch ein Computerprogramm, welches in dem Computer
gespeichert ist, gezielt aktiviert oder rekonfiguriert ist. Die
hier dargestellten Vorgänge
beziehen sich nicht inhärent
auf einen bestimmten Computer oder eine andere Vorrichtung. Verschiedene
Vielzweckmaschinen können
verwendet werden mit Programmen, die gemäß den hier beschriebenen Techniken
geschrieben sind, oder es kann sich als bequemer und zweckmäßiger erweisen,
speziellere Vorrichtungen zu konstruieren, um die erforderlichen Methodenschritte
bzw. Verfahrensschritte durchzuführen.
Die erforderliche Struktur für
eine Vielfalt dieser Maschinen ergibt sich aus der gegebenen Beschreibung.
Darüber
hinaus versteht es sich, daß eine
virtuelle Maschine, die mit der Erfindung konsistent ist, eine Funktionalität bereitstellen
kann, die über
die von früheren virtuellen
Maschinen hinausgeht, wie z. B. die virtuellen Maschinen, die in
der virtuellen Maschinenspezifikation von JavaTM beschrieben
werden.
-
Während die
JavaTM-Programmiersprache und -Plattform
für die
Erfindung geeignet sind, wäre
auch jede andere Sprache oder Plattform mit gewissen Eigenschaften
für die
Implementierung der Erfindung gut geeignet. Diese Eigenschaften
umfassen Typsicherheit, Zeigersicherheit, Objektorientiertheit,
dynamische Verknüpfung
und das Beruhen auf virtuellen Maschinen. Nicht alle dieser Eigenschaften
müssen
in einer bestimmten Implementierung vorhanden sein. In einigen Ausführungsformen
können
Sprachen oder Plattformen, die eine oder mehrere dieser Eigenschaften
nicht haben, verwendet werden. Eine „virtuelle Maschine" kann entweder in
Bits implementiert sein (virtuelle Maschine) oder in Silizium (reale/physikalische
Maschinen/anwendungsspezifische integrierte Schaltkreise). Auch
wenn die Erfindung unter Darstellung von objektweiser Sicherheit
dargestellt wurde, können
auch andere Ansätze,
wie z. B. eine klassenweise Sicherheit, verwendet werden.
-
Das
System der vorliegenden Erfindung kann in Hardware oder in Form
eines Computerprogramms implementiert werden. Jedes derartige Computerprogramm
kann auf einem Speichermedium oder einem Gerät (z. B. CD-ROM, Festplatte
oder magnetische Platte) gespeichert werden, welches durch einen
allgemeinen oder speziellen programmierbaren Computer lesbar ist,
um den Computer zu konfigurieren und zu betreiben, wenn das Speichermedium
oder -gerät
durch den Computer gelesen wird, und zwar in der Weise, daß die beschriebenen
Vorgänge
ausgeführt
werden. Das System kann auch als ein computerlesbares Speichermedium implementiert
sein, welches mit einem Computerprogramm konfiguriert wurde, wobei
das so konfigurierte Speichermedium bewirkt, daß ein Computer in einer spezifischen
und vordefinierten Weise arbeitet.
-
Das
Programm wird hier und allgemein als eine selbst-konsistente Folge
von Schritten verstanden, die zu einem gewünschten Ergebnis führen. Diese
Schritte sind diejenigen, die physikalische Manipulationen physikalischer
Größen erfordern. Üblicherweise,
wenn auch nicht notwendigerweise, nehmen diese Größen die Form
elektrischer oder magnetischer Signale an, welche gespeichert, übertragen,
kombiniert, verglichen und auf andere Weise manipuliert werden können. Mitunter
stellt es sich als zweckmäßig heraus,
insbesondere aus Gründen
einer allgemeinen Verwendung, diese Signale als Bits, Werte, Elemente,
Symbole, Zeichen, Begriffe, Ziffern oder dergleichen zu bezeichnen.
Es versteht sich jedoch, daß all
diese und ähnliche
Begriffe den passenden physikalischen Größen zugeordnet werden müssen und
lediglich zweckmäßige Etiketten
sind, die diesen Größen verpaßt werden.
-
Während die
Erfindung unter Bezug auf eine Ausführungsform dargestellt und
beschrieben wurde, verstehen Fachleute auf diesem Gebiet, daß die obigen
und andere Änderungen
hinsichtlich Form und Einzelheiten vorgenommen werden können, ohne
vom Geist und dem Umfang der folgenden Ansprüche abzuweichen.
-
Andere
Ausführungsformen
liegen innerhalb des Schutzumfangs der folgenden Ansprüche.
-
(AdÜ: Die Begriffe "Aufruf" und "Referenz" werden im Rahmen
der vorliegenden Beschreibung synonym verwendet, soweit sich aus
dem Zusammenhang nicht anderes ergibt.)