WO2007006697A1

WO2007006697A1 - Class loader tree traced on directory tree

Info

Publication number: WO2007006697A1
Application number: PCT/EP2006/063877
Authority: WO
Inventors: Laurent Jutard; Christophe Foesser
Original assignee: Gemplus
Priority date: 2005-07-08
Filing date: 2006-07-04
Publication date: 2007-01-18
Also published as: FR2888351A1

Abstract

The invention concerns the field of bytecode (pseudocode) loading in software environments. The invention concerns a method of dynamic class loading into a virtual machine of a computer system comprising a tree-like system for storing operating system data, characterized in that it includes: a step of recording class files in the tree-like storage system, a step of scanning the tree of the storage system, for at least one node of said tree, the node comprising at least one class file, a step of creating a class loader referencing the classes of the node and the classes of the parent node, a step of loading in said virtual machine the class loader.

Description

ARBORESCENCE OF CLASS CHARGERS CLOSED ON THE ARBORESCENCE OF DIRECTORIES

The present invention relates to the field of loading bytecodes (pseudo-codes) in interpreted software environments.

The present invention more particularly relates to a method and an architecture for loading such bytecodes, for example classes, offering the possibility, on the same virtual machine and at the same time, to execute different implementations of the same class and of to facilitate management.

In programming language environments, running Java programs requires that the source code of the program be compiled into Java pseudo-codes (bytecodes), which are interpreted by a virtual machine called Virtual Machine. Java source codes typically consist of classes stored in class files in the bytecode format, for example, Java Archive (JAR) files for Java (Business Name). A class is a set of variables and methods that model the behavior of an object. These classes are loaded into the virtual machine's memory using a class loader and then interpreted by the virtual machine. In order to optimize the management of the memory used by the virtual machine, the loading of the classes can be carried out dynamically during the execution of the program on the virtual machine, as in the embodiment described in more detail in FIG. US Pat. No. 6,470,494 or in US Patent Application 2004 / 261,069. dynamic loading provides the ability to only load classes or class versions in memory when they are used, thereby saving the resources of the virtual machine when executing the source code.

Dynamic class loader software solutions such as IBM's Eclipse (trade names) are already known. In the latter, all of the class files in the same folder are loaded using a single class loader.

However it may be desirable to run on the same virtual machine VM, several configurations substantially similar, that is to say, several implementations of the same class.

In common solutions, a variable called ClassPath (classpath) is used to locate the class file from the class name. In traditional operation, if two classes have the same name, the second is ignored. It is therefore not possible to have two implementations of the same class with the same name.

However, to allow the presence of two implementations of the same class, it is possible to duplicate the class by giving it another name, or to produce extension classes of the same class (concept of inheritance in object-oriented language ). When loading, a specific class loader is used for each of the two classes (or the two extended classes) that you want to implement. This solution has certain disadvantages, in particular:

- the difficulty of maintaining backward compatibility: how to ensure that the modification of a mother class does not affect the proper functioning of the girls classes?

- the architecture is fixed for an implementation,

- the maintenance is made difficult: if one wishes to modify an element common to all, it is necessary to modify all the classes and to update the ClassPath,

- the impossibility of unloading a class implementation without having to unload the virtual machine in its entirety,

- the difficulty in identifying the common parts that could be reused for a possible sharing of these classes with other modules.

There is therefore a need for a solution for loading classes offering the possibility, on the same virtual machine and at the same time, to execute different implementations of the same class, possibly bearing the same name, and to facilitate management thereof. .

The invention proposes to solve the disadvantages of the prior art by organizing and storing the bytecodes or classes in a data storage tree, for example a directory tree, and assigning a bytecode loader to each of the nodes of the tree. In particular, this tree makes it possible to preserve the class inheritance by organizing the parent classes in the parent directory of the child classes. Class loaders are mapped to the directory tree in which the class files are stored: the relationship between a classloader (class loader) affiliated with a directory and a classloader affiliated with the parent directory is the same as the one between a directory and the parent directory. The invention offers the following advantages:

- different implementations of the same class independently of their name, at the same time and on the same VM, are possible; indeed, two classloaders are created for two classes stored in two separate directories,

- class factorization using the directory tree to preserve the classical mechanism of inheritance by placing the parent classes in a parent directory. This factorization then provides a modular organization of classes, allowing a faster loading into the virtual machine and a possible and targeted unloading without stopping the execution of the virtual machine (the management of the memory is then greatly simplified), - a cycle specific life for each of the implementations of the class allowing management and maintenance (own evolution of the properties, independent loading or unloading) of the implementation independently of the others: any modification on a class implementation does not affect the other classes.

The invention applies particularly to HMIs (Human Machine Interface) implementing similar objects with different specificities or functionalities. For example, a smart card programming software that must present, on the same API programming interface, identical card operations even though these cards have different hardware resource specificities from one to the other. In this respect, the invention makes it possible to create sets of common classes (parent classes) to all the card configurations and more specific parts (daughter classes) in subdirectories specific to each of the cards. To this end, the invention relates, in its most general sense, to a dynamic class loading method in a virtual machine of a computer system comprising a tree system for storing data of the operating system, characterized in that 'He understands :

a step of registering class files in the nodes of the storage system tree,

a step of scanning the tree,

for at least one node of said tree, the node comprising at least one class file, a step of creating a class loader referencing the classes of the node and the classes of the parent node, a step of loading in said class loader virtual machine.

In an appropriate embodiment for maintaining class inheritance (eg, class inheritance), said created class loader references classes of the class loader of said parent node.

In particular, the class loader of the root node only references the classes of the root node. This initiates loading for the most upstream node. In another embodiment, the class loader of the root node references classes of the root node and default classes.

In a particular embodiment, said tree respects inheritance between classes.

The invention also relates to an architecture for the dynamic loading of classes in a virtual machine of a computer system comprising a system for storing data in a tree structure, characterized in that it comprises a plurality of class files organized in the nodes of the storage system tree and a plurality of class loaders each corresponding to a node containing at least one class file, said class loaders referencing the classes of the storage system. corresponding node and the classes of the parent node.

In one embodiment, said created class loaders each reference classes of the class loader of their parent node.

In another embodiment, said class loaders are organized according to a tree structure mapped to said tree of storage system nodes.

In a particular embodiment, the architecture comprises at least two classes bearing the same name in two different nodes having the same parent node.

In particular, said tree respects inheritance between classes.

The invention will be better understood using the description, given below purely for explanatory purposes, of an embodiment of the invention, with reference to the appended FIG. 1 which illustrates the mapping of class loaders on the directory tree.

The embodiment for the description which follows addresses the invention in the context of a programming software for smart cards, as previously introduced, which must take into account different profiles or hardware configurations of cards. For each profile, a set of classes is developed to manage a specific card. Such software makes it possible to program actions to be performed (the program code is in Java) on a map Java by calling classes. To simplify the management of the increasing number of different cards, it is interesting to be able to manage the different cards by using different versions or implementations of the same class, the implementations bearing the same name and each one of them reflecting the material particularities of the cards. cards. In the example of FIG. 1, two different card configurations are used: GXXv3.2 and GX3Gv2.2. By implementation is meant the development of a new source code, here the Java code for defining and describing classes.

Also for the sake of simplicity, we will use, in the following example, only one class file per directory and one class per file, whereas the invention can be implemented with several JAR files in the file. same directory and several classes within the same archive file, whether or not these classes have a parent class in the archived file (s) of the parent directory. It is understood that, even if the Java language has been mentioned above, the invention can be applied to many programming languages that can generate an interpretable bytecode, for example the object-oriented languages C ++ or C # used in the "framework" .Net "(Microsoft Software Development Platform - Business Name).

*** The class tree ***

Referring to Figure 1, jar files (Java ARchive for Java2) classes, for example "corecommands. jar ", are registered in the operating system file system directories, for example the folder" GXXv3.2 ". Directories from all levels of the tree are likely to receive a or archived JAR files. The file system tree is the hierarchical organization structure of folders and subfolders (or directories) whose shape is similar to that of a tree.

The parent directory "Lib" contains an archived file "commandframework. jar "which contains the definition of the class" SendAPDU. class ".

The child directory "GXXv3.2" also contains an archived file "corecommands. jar "containing the definition of the class" Create. class "whose class" SendAPDU. class "is a parent class in the sense of class inheritance in object-oriented languages.

Another "GX3Gv2.2" child directory in the "Lib" directory also contains an archived file of the same name "corecommands. jar "and / or containing another definition of the same class" Create. class "whose class" SendAPDU. class "is a parent class in the sense of class inheritance. This other file "corecommands. jar "contains an implementation of the class" Create. class "different from that of the first file to satisfy the hardware specificities of the smart card associated with the type GX3Gv2.2.

The two classes "Create. class "define the same class (hence the same name) for different configurations: the GXXv3.2 configuration for the first, GX3Gv2.2 for the second. Their definition differs in terms of the computer code registered in the JAR class files.

*** ClassLoaders ***

When one wishes to execute, on the virtual machine, the program making use of these classes, a scan of the directory tree is from the root to the deepest level directories. During this scan of the tree, all archived JAR files are identified as well as their directories. In the root directory, "Lib" in the example of Figure 1, the JAR file "commandframework. jar "is detected. Still referring to Figure 1, a class loader "LibClassLoader" is then created, loads the class "SendAPDU. class "and the reference so that the virtual machine can access it. In Java language, this operation can be performed by the following function:

URLClassLoader LibClassLoader = new URLClassLoader (URLU "/ Lib /")

Class loading also references previously loaded classes in the virtual machine, for example the default classes loaded by the static ClassPath when the virtual machine is launched.

The default classes as well as the class "SendAPDU. class "can be instantiated in the virtual machine by the" LibClassLoader "class loader.

When browsing the tree, the child directory "GXXv3.2" is detected as containing a class archive file "corecommands." jar ". A class loader "GXXv32ClassLoader" is then created by referencing the classes contained in its "GXXv3.2" directory, namely "Create. class "and the classes contained in the parent directory" Lib ", namely" SendAPDU. class ". This operation can be performed by the Java function:

URLClassLoader GXXv32ClassLoader = new URLClassLoader (URLU 7Lib / GXXv3.21 ", LibClassLoader)

In this function, we pass in parameter the path "/Lib/GXXv3.2/" of the directory to load the classes of all the JAR files present in the directory, here the only file "corecommands. jar ". In the function, we also pass the parent class loader parameter (here "LibClassLoader"). "LibClassLoader" has already loaded the classes of the "Lib" directory and these classes are passed to the newly created class loader, a "LibClassLoader" class loader. By this function, the "GXXv32ClassLoader" loader references not only "Create.class" and "SendAPDU. class "but also the other classes that reference" LibClassLoader ", ie in this example the default Java classes. Thus all these classes ("Create.class", "SendAPDU class" and the default classes) can be instantiated by this class loader.

It should be noted that with a deep tree (several levels), the classes loaded in a class loader are all those of the parent directories: level 1 parent directory, level 2, ..., and the default classes.

Similarly, when browsing the tree, the other child directory "GX3Gv2.2" is detected and the class file "corecommands. jar "associate also. A "GX3Gv22ClassLoader" class loader is then created by referencing the classes contained in its "GX3Gv2.2" directory, namely "Create.class" and the classes contained in the "Lib" parent directory, namely "SendAPDU. class ". This operation can be performed by the Java function:

URLClassLoader GX3Gv22ClassLoader = new URLClassLoader (URLt] 7Lib / GX3Gv2.2 / ", LibClassLoader)

By this function, the "GX3Gv22ClassLoader" loader references not only "Create.class" and "SendAPDU. class "but also the other classes that reference" LibClassLoader ", namely in this example the Java classes by default. Thus all these classes ("Create.class", "SendAPDU. Class" and the default classes) can be instantiated by this class loader "GX3Gv22ClassLoader".

In this configuration, two definitions / implementations of the same class under the same name coexist in "brother" directories (directories with the same parent directory). The two JAR files are separate and the class implementations are completely separated in the virtual machine when running the program through the separation of the class loaders, even if the classes have the same name. The use of such a tree is advantageous for accessing both different configurations (the two classes "Create.class") and common configurations (the class "SendAPDU.class"), for example for chip whose general operation is identical but some hardware configurations may differ.

The class loaders "GXXv32ClassLoader" and "GX3Gv22ClassLoader" have therefore as parent class loader "LibClassLoader". The relationship between a class loader associated with a directory and a class loader associated with the parent directory is the same as the link between the two directories; class loaders are then mapped to the directory tree: it is clear that, by the present invention, the class loader tree can be dynamically created and mapped to the directory tree.

It is of course planned not to be limited to two levels of tree and to exceed the example presented. For example, if the hardware configuration of the smart card "GX3Gv2.2" is divided into two sub-configurations, we can create two child sub-directories of the "GX3Gv2.2" directory, each with a class of the same name but specific to each of the two sub-configurations. The class loaders associated with the two child subdirectories then reference their own class as well as the mother classes of the "GX3Gv22ClassLoader" loader.

Thus, the programming software can use the "GX3Gv22ClassLoader" loader or the "GXXv32ClassLoader" loader to create the instance of the "Create.class" class.

*** Modification of a class ***

During a maintenance operation, one may have to modify / update a class implementation, for example the "GX3Gv2.2" implementation of the "Create.class" class. The source code of the "Create.class" class is then modified in the "corecommands" class file. jar "from the folder" GX3Gv2.2 ". This change has no impact on the file "corecommands. jar "from the directory" GXXv3.2 "and the run-time behavior of the" Create.class "class of the" GXXv3.2 "implementation since the" GXXv32ClassLoader "loader does not load the file class file" GX3Gv2.2 ".

The modular organization allows to modify a class independently of other implementations of the same class: each implementation of a class has a life cycle of its own.

Similarly, since the class "SendAPDU. class "is shared for both" GXXv3.2 "implementations and "GX3Gv2.2", a modification of the properties of the class "SendAPDU. class "is taken into account by the two class loaders" GXXv32ClassLoader "and" GX3Gv22ClassLoader ". The invention thus makes it possible to factorize the common source code (a class for example) with several implementations in order to facilitate maintenance: a single loader is used by the different implementations to load the common parts of code.

*** Unloading a class ***

A lot of research has been done to optimize the management of memory in virtual machines. To this end, the present invention allows the virtual machine to recover a portion of the memory without having to stop the execution of this virtual machine. This is possible by performing loader class unloading. A class loader can then be destroyed and the virtual machine recovers the affected memory when the garbage collector is triggered. To implement this unloading, you can modify the class loader reference by setting it to NULL in the management code. The consequence of this modification is the loss of the references to the loaded classes, and thus the recovery, during the passage of the garbage collector, of the memory space which was allocated to them.

Claims

A method of dynamically loading classes in a virtual machine of a computer system comprising a tree system for storing data of the operating system, characterized in that it comprises:

a step of registering class files in the nodes of the storage system tree,

a step of scanning the tree, for at least one node of said tree, the node comprising at least one class file, a step of creating a class loader referencing the classes of the node and the classes of the parent node, o a loading step in said class loader virtual machine.

2. Method according to the preceding claim, characterized in that said created class loader references the class loader classes of said parent node.

3. Method according to the preceding claim, characterized in that the class loader of the root node references only the classes of the root node.

4. Method according to claim 2, characterized in that the class loader of the root node references the classes of the root node and the default classes.

5. Method according to claim 1, characterized in that said tree respects inheritance between classes.

An architecture for dynamically loading classes into a virtual machine of a computer system having a tree-based data storage system, characterized in that it comprises a plurality of class files organized in the nodes of the tree structure. storage system and a plurality of class loaders each corresponding to a node containing at least one class file, said class loaders referencing classes of the corresponding node and classes of the parent node.

7. Architecture according to the preceding claim, characterized in that said class loaders created refer each classes of the class loader of their parent node.

8. Architecture according to the preceding claim, characterized in that said class loaders are organized according to a tree structure mapped on said tree of the nodes of the storage system.

9. Architecture according to claim 6, characterized in that it comprises at least two classes bearing the same name in two different nodes having the same parent node.

10. Architecture according to claim 6, characterized in that said tree respects inheritance between classes.