Le modèle de méta-données JavaCard ( gure 5.5, page 86), qui est aussi celui du chier CAP, est beaucoup plus complexe que celui de KVM. Le modèle JavaCard est un emboîtement de petites structures basées sur des entiers d'au maximum 16bits. Ce modèle est découpé en 12 composants qui regroupent les méta-données par catégories d'usage, plus que par types. On y trouve des classiques comme par exemple le composant Class, Method,ConstantPool, etc (La liste complète est disponible dans [JCVM.2.2.1 2003]). Toutefois, toutes les informa- tions constituant habituellement les méta-données Classe ou Méthode ne sont pas stockées dans un composant unique. Une partie est par exemple déportée dans un autre composant appelé Descriptor. Ce composant contient des méta-données descriptives par opposition aux méta-données exécutives, celles utilisées dans le ot d'exécution des bytecodes listées section 5.3.1, page 81, et contenues dans le deux premiers composants.
La grosse diérence avec le modèle standard tient dans l'absence des chaînes de carac- tères dans les spéci cations Java pour JavaCard. Ceci a pour conséquence de les exclure également des méta-données. La recherche symbolique d'une classe ou d'une méthode ne peut donc se faire sur son nom. Au lieu de cela, l'étape de conversion aecte aux classes, interfaces, méthodes et champs, un jeton sous forme d'un entier 16 bits qui sert à les iden- ti er dans le modèle de données. Chaque jeton est unique à l'intérieur d'un paquetage JavaCard (i.e un cher CAP) et réduit donc considérablement l'empreinte nécessaire pour lier les méta-données entre elles dans le modèle.
Néanmoins, le modèle JavaCard utilise toujours un ConstantPool, même si celui-ci est compacté à la conversion sur le modèle de la Romisation. Ce ConstantPool entretient un minimum de symbolisme pour les bytecodes utilisant des méta-données. Ce qui permet de lier les chiers de CAP entre eux, lors de leur installation sur la carte à puce.
5.4.2 Motifs d'accès revisités
Du fait de modèles diérents, les chemins d'accès aux méta-données ne sont pas exactement les mêmes entre JavaCard et KVM. Nous reprenons notre exemple le plus complexe, à savoir la résolution de méthodes virtuelles, pour mettre en évidence les similitudes et diérences entre ces deux modèles.
Le diagramme 5.4, page 83 peignant la résolution de méthodes virtuelles reste valable dans ces grandes lignes pour JavaCard. Il y a toujours deux phases ; une résolution de liens dans le ConstantPool, et une recherche de la bonne méthode dans la hiérarchie des classes. Toutefois, chaque étape est grandement simpli é en terme de données accédées. JavaCard distingue ainsi méthodes virtuelles internes au CAP de celles externes. Une classe JavaCard possède donc deux tables de méthodes virtuelles. Le diagramme 5.4 est remplacé pour JavaCard par le Listing 5.3, page 87, en pseudo-code, pour plus de lisibilité de cette distinction.
Dans chaque table d'une classe, un index est strictement égal à un jeton de méthode, et ce, relativement à la première méthode virtuelle dé nie dans la classe, appelée base. L'entrée à cet index contient l'oset de cette méthode dans le composant Method. De plus, la hiérarchie des index des tables suit la hiérarchie des classes. Ainsi, le premier index dans
Listing 5.3: Résolution de méthode virtuelle JavaCard
entrée : bytecode= INVOKEVIRTUAL, operande = XX
// PHASE 1
methodToken := pool[operande].virtual_method_ref.virt_method_token classToken := pool[operande].virtual_method_ref.class
si classToken estInterneAuCAP alors
classInfo := class_component.class_info[refClass.internal_ref]
sinon
capToken := refClass.external_ref.package_token classToken := refClass.external_ref.class_token
classInfo := chercheClassExportée(capToken,classToken)
fin si
si methodToken & 0x80 alors
base = classInfo.package_methode_table_base
tant que methodToken < base
classInfo= classInfo.superclass
base = classInfo.package_methode_table_base
fin tant que
methodInfo := classInfo.package_methode_table[methodToken-base]
sinon
base = classInfo.public_methode_table_base
tant que methodToken < base
classInfo= classInfo.superclass
base = classInfo.public_methode_table_base
fin tant que
methodInfo := classInfo.public_methode_table[methodToken-base]
fin si // PHASE 2
this := sommetPile - methodInfo.argcount dynClass := this.class
tant que dynClass != java.lang.Object
si methodToken & 0x80 alors
index := methodToken - dynClass.package_methode_table_base
si index < dynClass.package_methode_table_size alors
dynMethod= dynClass.package_methode_table[index]
fin si sinon
index := methodToken - dynClass.public_methode_table_base
si index < dynClass.public_methode_table_size alors
dynMethod= dynClass.public_methode_table[index]
fin si fin si
dynClass := dynClass.superclass
fin tant que
retourner dynMethod
la table d'une classe lle suit le dernier index de la table de la classe mère (Phase 2 du Listing 5.3), grâce à un calcul simple sur la base . Ce qui permet de remonter quasiment directement dans la hiérarchie des classes parentes sans recherche itérative par classes. Par rapport au modèle de KVM, l'appel d'une méthode virtuelle est donc fortement simpli ée à ce niveau.
appelé ReferenceLocation. Ce composant liste tous les osets dans le composant Method où se situe une référence dans le ConstantPool. Grâce à ce composant, il est alors facile de résoudre partiellement presque toutes les références symboliques restantes à l'installation. Cette résolution partielle est la suivante.
La Phase 1 sert uniquement à trouver le nombre d'argument de la méthode à appeler pour localiser l'objet this sur la pile. Quelque soit sa localisation dans la hiérarchie des classes, cette méthode virtuelle aura toujours le même nombre d'argument. Grâce au com- posant ReferenceLocation, il est alors facile de stocker une information permettant de retrou- ver rapidement ce nombre d'argument. Avec cette résolution précoce, qui peut être réalisée à l'installation, la Phase 1 peut alors être évitée dans la plupart des cas.