DE60031370T2

DE60031370T2 - Tokenbasierte verknüpfung

Info

Publication number: DE60031370T2
Application number: DE60031370T
Authority: DE
Inventors: E. Judith San Mateo SCHWABE; B. Joshua San Francisco SUSSER
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1999-02-02
Filing date: 2000-02-02
Publication date: 2007-09-20
Anticipated expiration: 2020-02-03
Also published as: CN1160626C; KR100713739B1; CN1324467C; AU2004202909B2; BRPI0007945B1; BR0007945A; EP1145107A2; AU771699B2; WO2000046667A2; CN1346465A; AU3587200A; JP2002536744A; CA2362010A1; US6880155B2; US20050097550A1; EP1145107B1; ATE343172T1; DE60031370D1; US20030028686A1; US7444631B2

Description

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 Java^TM-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 Windows^TM-Basis ausgeführt wird, denselben Satz von Befehlen wie eine virtuelle Maschine, die auf einem Computersystem auf UNIX^TM 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 Java^TM-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 Java^TM beschrieben werden.
Während die Java^TM-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.)

Claims

Verfahren zum Herunterladen von Code (10) in einen ressourcenbeschränkten Computer (40), wobei der Code in zumindest ein Paket trennbar ist, das zumindest einen referenzierbaren (aufrufbaren) Gegenstand hat, wobei das Verfahren aufweist: Bilden des Paketes (16), Bilden einer Zuordnung des referenzierbaren Gegenstandes zu einem entsprechenden Token (84), der einen Tokentyp hat, wobei es eine Mehrzahl von Tokentypen gibt, wobei Token, die zu demselben Tokeytyp gehören, dieselbe Art von referenzierbarem Gegenstand wiedergeben, jede Art von referenzierbarem Gegenstand in dem Paket ihren eigenen unabhängigen Umfang für Token des entsprechenden Tokentyps hat und Bereitstellen des Paketes und der Zuordnung.
Verfahren nach Anspruch 1, welches weiterhin das Aufzeichnen einer Zuordnung zwischen dem Token und dem referenzierbaren Gegenstand in einem Bild (200, 174) des Paketes aufweist.
Verfahren nach Anspruch 1 oder 2, wobei der referenzierbare Gegenstand eine Klasse aufweist und die Referenz bzw. der Aufruf (180) ein Paket- und ein Klassentoken aufweist.
Verfahren nach Anspruch 1 oder 2, wobei der referenzierbare Gegenstand ein Feld aufweist und wobei die Referenz (182) ein Paket-, ein Klassen- und ein Feldtoken aufweist.
Verfahren nach Anspruch 1 oder 2, wobei der referenzierbare Gegenstand ein Verfahren aufweist und die Referenz bzw. der Aufruf (184) ein Paket-, ein Klassen- und ein Methodentoken aufweist.
Verfahren nach einem der Ansprüche 1 bis 5, wobei das Paket weiterhin Schnittstellen und Definitionen von Schnittstellenmethoden aufweist, und wobei das Verfahren weiterhin den Schritt aufweist, daß zumindest eine Schnittstellenmethodentabelle für eine Klasse konstruiert wird.
Verfahren nach Anspruch 6, wobei der Schritt des Konstruierens aufweist: Erhalten bzw. Gewinnen der Schnittstellen, Konstruieren einer geordneten Tabelle von Methoden für jede Schnittstelle und Aufzeichnen einer Anzeige der Implementierung der Schnittstellenmethode für jeden Tabelleneintrag.
Verfahren nach Anspruch 7, wobei die Einträge in die geordnete Schnittstellenmethodentabelle den Tokenwerten entsprechen, welche innerhalb des Umfanges der Klasse den Schnittstellenmethoden zugeordnet sind.
Verfahren nach Anspruch 8, wobei die Anzeige der Implementierung der Schnittstellenmethode einen Index auf eine virtuelle Methodentabelle aufweist.
Verfahren nach Anspruch 1, wobei der referenzierbare Gegenstand ein intern referenzierbarer Gegenstand ist und wobei das Token ein optimierter numerischer Wert ist, wobei das Verfahren den zusätzlichen Schritt aufweist: Ersetzen von Referenzen auf zumindest einen intern referenzierbaren Gegenstand durch den entsprechenden numerischen Wert.
Verfahren nach Anspruch 10, wobei das Paket weiterhin zumindest eine Referenz auf einen internen Gegenstand aufweist.
Verfahren nach Anspruch 11, wobei der interne Gegenstand zumindest eine Klasse aufweist und wobei die Referenz (der Aufruf) einen Versatz bzw. eine Verschiebung innerhalb des Paketes zu einer Klassenaufzeichnung aufweist, die der Klasse zugeordnet ist.
Verfahren nach Anspruch 11, wobei der interne Gegenstand ein statisches Feld aufweist und wobei die Referenz einen Versatz innerhalb des Paketes zu einem Wert für das statische Feld aufweist.
Verfahren nach Anspruch 11, wobei der interne Gegenstand eine statische Methode aufweist und wobei die Referenz einen Versatz innerhalb des Paketes zu Code aufweist, welcher der statischen Methode zugeordnet ist.
Verfahren nach Anspruch 11, wobei der interne Gegenstand ein Instanzenfeld aufweist und wobei die Referenz einen Versatz innerhalb des Paketes zu einer Klassenaufzeichnung des Instanzenfeldes und ein Feldtoken aufweist.
Verfahren nach Anspruch 11, wobei der interne Gegenstand eine virtuelle Methode aufweist und wobei die Referenz einen Versatz innerhalb des Paketes zu einer Klassenaufzeichnung der virtuellen Methode und einen Methodentoken aufweist.
Verfahren zum Konstruieren bzw. Aufbauen eines Bildes aus einem ersten Paket von Code auf einem Computer, wobei der Code in zumindest ein Paket (200) abtrennbar ist, welches zumindest eine Referenz auf einen Gegenstand in einem zweiten Paket (174) von Code hat, wobei das Verfahren aufweist: Empfangen einer Zuordnung des Gegenstandes zu zumindest einem entsprechenden Token, welcher einen Tokentyp aufweist, wobei es eine Mehrzahl von Tokentypen gibt, wobei Token, die zu demselben Tokentyp gehören, dieselbe Art von referenzierbarem Gegenstand repräsentieren, wobei jede Art von referenzierbarem Gegenstand in dem Paket ihren eigenen unabhängigen Umfang für Token des entsprechenden Tokentyps hat, Ersetzen der zumindest einen Referenz durch den zumindest einen entsprechenden Token und Bilden des Paketes.
Verfahren zum Verknüpfen von Code, welcher in einen ressourcenbeschränkten Computer (40) heruntergeladen wird, wobei der Code in zumindest ein Paket trennbar ist, das zumindest einen referenzierbaren Gegenstand hat, und welches aufweist: Empfangen des Paketes (18), Empfangen einer Zuordnung des referenzierbaren Gegenstandes zu einem entsprechenden Token (84), der einen Tokentyp hat, wobei es eine Mehrzahl von Tokentypen gibt, wobei Token, die zu demselben Tokentyp gehören, dieselbe Art von referenzierbarem Gegenstand repräsentieren, wobei jede Art von referenzierbarem Gegenstand in dem Paket ihren eigenen unabhängigen Schutz für Token des entsprechenden Tokentyps hat, und Verknüpfen bzw. Verlinken des Paketes unter Verwendung der Zuordnung.
Verfahren nach Anspruch 18, wobei das Paket eine Zuordnung von Token zu extern referenzierbaren Gegenständen umfaßt, und wobei das Verfahren die weiteren Schritte aufweist: Empfangen eines zweiten Paketes, das zumindest eine Referenz auf einen Gegenstand in dem Paket aufweist, wobei die Referenz durch einen oder mehrere Token repräsentiert wird, die einen Tokentyp haben, wobei Token, die zu demselben Tokentyp gehören, dieselbe Art von referenzierbarem Gegenstand repräsentieren, wobei jede Art von referenzierbarem Gegenstand in dem Paket ihren eigenen unabhängigen Umfang für Token des entsprechenden Tokentyps hat, und Verknüpfen des zweiten Paketes mit dem ersten Paket durch Auflösen des einen oder der mehreren Token.
Verfahren nach Anspruch 19, welches weiterhin das Aufzeichnen einer Zuordnung zwischen dem Token und dem referenzierbaren Gegenstand in einem Bild des Paketes aufweist.
Verfahren nach Anspruch 19, wobei der referenzierbare Gegenstand eine Klasse aufweist und die Referenz (bzw. der Aufruf) (180) ein Paket- und ein Klassentoken aufweist.
Verfahren nach Anspruch 19, wobei der referenzierbare Gegenstand ein Feld aufweist und die Referenz (182) ein Paket-, ein Klassen- und ein Feldtoken aufweist.
Verfahren nach Anspruch 19, wobei der referenzierbare Gegenstand eine Methode aufweist und wobei die Referenz (184) ein Paket-, ein Klassen- und ein Methodentoken aufweist.
Verfahren nach Anspruch 19, welches weiterhin das Auflösen von Schnittstellenmethodenreferenzen während des Ausführens unter Verwendung von Schnittstellenmethodentabellen aufweist, wobei das Auflösen aufweist: Erhalten einer zugeordneten Instanz, Erhalten einer Klassenbeschreibung der Instanz, Lokalisieren einer Schnittstellentabelle der Schnittstellenmethode in der Klassenbeschreibung, Lokalisieren eines Schnittstellenmethodeneintrags innerhalb einer Schnittstellentabelle einer referenzierten Methode, und Lokalisieren der Implementierung der Schnittstellenmethode auf der Basis des Inhaltes des Tabelleneintrags.
Verfahren nach Anspruch 24, wobei eine Anzeige der Implementierung der Schnittstellenmethode einen Index in einer virtuellen Methodentabelle aufweist.
Computerprogramm, welches Codeeinrichtungen aufweist, die, wenn sie auf einem Computersystem ausgeführt werden, das Computersystem anweisen, das Verfahren nach einem der vorstehenden Ansprüche auszuführen.
Vorrichtung zum Herunterladen von Code (10) in einen ressourcenbeschränkten Computer (40), wobei der Code in zumindest ein Paket trennbar ist, das zumindest einen referenzierbaren Gegenstand hat, und welches aufweist: eine Einrichtung zum Bilden des Paketes (16), eine Einrichtung zum Herstellen einer Zuordnung des referenzierbaren Gegenstandes zu einem entsprechenden Token (84), der einen Tokentyp hat, wobei es eine Mehrzahl von Tokentypen gibt, wobei Token, die zu demselben Tokentyp gehören, dieselbe Art von referenzierbarem Gegenstand repräsentieren, wobei jede Art von referenzierbarem Gegenstand in dem Paket ihren eigenen unabhängigen Umfang für Token des entsprechenden Tokentyps hat, und eine Einrichtung zum Bereitstellen des Paketes und der Zuordnung.
Vorrichtung nach Anspruch 27, welches weiterhin eine Einrichtung zum Aufzeichnen einer Zuordnung zwischen dem Token und dem referenzierbaren Gegenstand in einem Bild (200, 174) des Paketes aufweist.
Vorrichtung nach Anspruch 27, wobei der referenzierbare Gegenstand eine Klasse aufweist und wobei die Referenz (180) ein Paket- und ein Klassentoken aufweist.
Vorrichtung nach Anspruch 27, wobei der referenzierbare Gegenstand ein Feld aufweist und wobei die Referenz (182) ein Paket-, ein Klassen- und ein Feldtoken aufweist.
Vorrichtung nach Anspruch 27, wobei der referenzierbare Gegenstand eine Methode aufweist und wobei die Referenz (184) ein Paket-, ein Klassen- und ein Methodentoken aufweist.
Vorrichtung nach Anspruch 27, wobei das Paket weiterhin Schnittstellen und Definitionen von Schnittstellenmethoden aufweist, und die Vorrichtung weiterhin eine Einrichtung zum Konstruieren bzw. Aufbauen zumindest einer Schnittstellenmethodentabelle für eine Klasse aufweist.
Vorrichtung nach Anspruch 32, wobei das Konstruieren aufweist: eine Einrichtung zum Erhalten der Schnittstellen, eine Einrichtung zum Konstruieren einer geordneten Tabelle von Methoden für jede Schnittstelle, und eine Einrichtung zum Aufzeichnen einer Anzeige für die Implementierung der Schnittstellenmethode für jeden Tabelleneintrag.
Vorrichtung nach Anspruch 33, wobei die Einträge der geordneten Schnittstellenmethodentabelle Tokenwerten entsprechen, die den Schnittstellenmethoden innerhalb des Umfanges der Klasse zugeordnet sind.
Vorrichtung nach Anspruch 34, wobei die Anzeige der Implementierung der Schnittstellenmethode einen Index auf eine virtuelle Methodentabelle aufweist.
Vorrichtung nach Anspruch 27, wobei der referenzierbare Gegenstand ein intern referenzierbarer Gegenstand ist und wobei der Token ein optimierter numerischer Wert ist, wobei die Vorrichtung weiterhin aufweist: eine Einrichtung zum Ersetzen von Referenzen auf den zumindest einen internen referenzierbaren Gegenstand durch den entsprechenden numerischen Wert.
Vorrichtung nach Anspruch 36, wobei das Paket weiterhin zumindest eine Referenz auf einen internen Gegenstand aufweist.
Vorrichtung nach Anspruch 37, wobei der interne Gegenstand eine Klasse aufweist und die Referenz einen Versatz innerhalb des Paketes zu einer Klassenaufzeichnung aufweist, die zu der Klasse gehört.
Vorrichtung nach Anspruch 37, wobei der interne Gegenstand ein statisches Feld aufweist und wobei die Referenz einen Versatz innerhalb des Paketes auf einen Wert für das statische Feld aufweist.
Vorrichtung nach Anspruch 37, wobei der interne Gegenstand eine statische Methode aufweist und wobei die Referenz einen Versatz innerhalb des Paketes auf Code aufweist, der der statischen Methode zugeordnet ist.
Vorrichtung nach Anspruch 37, wobei der interne Gegenstand ein Instanzenfeld aufweist und wobei die Referenz einen Versatz innerhalb des Paketes zu einer Klassenaufzeichnung des Instanzenfeldes und ein Feldtoken aufweist.
Vorrichtung nach Anspruch 37, wobei der interne Gegenstand eine virtuelle Methode aufweist und wobei die Referenz einen Versatz innerhalb des Paketes zu einer Klassenaufzeichnung der virtuellen Methode und ein Methodentoken aufweist.
Vorrichtung zum Verknüpfen von Code, der auf einen ressourcenbeschränkten Computer (40) heruntergeladen wurde, wobei der Code in zumindest ein Paket trennbar ist, das zumindest einen referenzierbaren Gegenstand hat, und welche aufweist: eine Einrichtung zum Empfangen des Pakets (16), eine Einrichtung zum Empfangen einer Zuordnung des referenzierbaren Gegenstandes zu einem entsprechenden Token (84), der einen Tokentyp hat, wobei es eine Mehrzahl von Tokentypen gibt, und Token, die zu demselben Tokentyp gehören, dieselbe Art von referenzierbarem Gegenstand repräsentieren, wobei jede Art von referenzierbarem Gegenstand in dem Paket ihren eigenen unabhängigen Umfang für Token des entsprechenden Tokentyps hat, und eine Einrichtung zum Verknüpfen bzw. Verlinken des Paketes unter Verwendung der Zuordnung.
Vorrichtung nach Anspruch 43, wobei das Paket eine Zuordnung von Token zu extern referenzierbaren Gegenständen hat, wobei die Vorrichtung weiterhin aufweist: eine Einrichtung zum Empfangen eines zweiten Paketes, welches zumindest eine Referenz auf einen Gegenstand in dem ersten Paket aufweist, wobei die Referenz durch ein oder mehrere Token repräsentiert wird, die einen Tokentyp haben, wobei Token, welche zu demselben Tokentyp gehören, dieselbe Art von referenzierbarem Gegenstand repräsentieren, wobei jede Art eines referenzierbaren Gegenstandes in dem Paket ihren eigenen unabhängigen Umfang für Token des entsprechenden Tokentyps hat, und eine Einrichtung zum Verknüpfen des zweiten Paketes mit dem ersten Paket durch Auflösen des einen oder der mehreren Token.
Vorrichtung nach Anspruch 44, welches weiterhin eine Einrichtung zum Aufzeichnen einer Zuordnung zwischen dem Token und dem referenzierbaren Gegenstand in einem Abbild des Paketes aufweist.
Vorrichtung nach Anspruch 44, wobei der referenzierbare Gegenstand eine Klasse aufweist und wobei die Referenz ein Paket- und ein Klassentoken aufweist.
Vorrichtung nach Anspruch 44, wobei der referenzierbare Gegenstand ein Feld aufweist und wobei die Referenz ein Paket-, ein Klassen- und ein Feldtoken aufweist.
Vorrichtung nach Anspruch 44, wobei der referenzierbare Gegenstand eine Methode aufweist und wobei die Referenz ein Paket-, ein Klassen- und ein Methodentoken aufweist.
Vorrichtung nach Anspruch 44, welche weiterhin eine Einrichtung zum Auflösen von Schnittstellenmethodenreferenzen während der Ausführung unter Verwendung von Schnittstellenmethodentabellen aufweist, wobei die Einrichtung zum Auflösen aufweist: eine Einrichtung zum Erhalten einer zugehörigen Instanz, eine Einrichtung zum Erhalten einer Klassenbeschreibung der Instanz, eine Einrichtung zum Lokalisieren einer Schnittstellentabelle der Schnittstellenmethode in der Klassenbeschreibung, eine Einrichtung zum Lokalisieren eines Schnittstellenmethodeneintrages innerhalb einer Schnittstellentabelle einer referenzierten Methode und eine Einrichtung zum Lokalisieren der Implementierung der Schnittstellenmethode auf der Basis des Inhaltes des Tabelleneintrags.
Vorrichtung nach Anspruch 49, wobei eine Anzeige der Implementierung der Schnittstellenmethode einen Index zu einer virtuellen Methodentabelle aufweist.
Vorrichtung zum Konstruieren eines Abbildes eines ersten Paketes von Code auf einem Computer, wobei der Code in zumindest ein Paket (200) separierbar ist, das zumindest eine Referenz auf einen Gegenstand in einem zweiten Paket (174) von Code hat, wobei die Vorrichtung aufweist: eine Einrichtung zum Empfangen einer Zuordnung des Gegenstandes zu zumindest einem entsprechenden Token, der einen Tokentyp hat, wobei es eine Mehrzahl von Tokentypen gibt, wobei Token, welche zu demselben Tokentyp gehören, dieselbe Art von referenzierbarem Gegenstand repräsentieren, wobei jede Art von referenzierbarem Gegenstand in dem Paket ihren eigenen unabhängigen Umfang für Token des entsprechenden Tokentyps hat, eine Einrichtung zum Ersetzen der zumindest einen Referenz durch das zumindest eine entsprechende Token, und eine Einrichtung zum Ausbilden des Paketes.