Java card Virtual Machine (jcvm)

Java card Virtual Machine (jcvm) Specification defines JavaProgramA subset of the design language and a Java-compatible Virtual Machine for smart cards, including binary data representation and file formats, and jcvm instruction sets.

The Virtual Machine Used for the Java card platform is implemented in two parts, one is on the outside of the card, and the other is on the card itself. The Java card virtual machine on the card interprets bytecode, management classes, and objects. The external Java virtual machine is a development tool, which is generally called a Java card conversion tool. It loads, verifies, and further prepares the Java class of the card applet for execution on the card. The Conversion Tool outputs a converted applet (CAP) file, which contains all classes in a Java package. Whether the Conversion Program inspection class complies with the Java card specification.

Jcvm only supports a limited subset of the Java programming language. However, it retains many familiar features, including objects, inheritance, packages, dynamic object creation, virtual methods, interfaces, and exceptions. The jcvm specification gives up support for many language elements, because these language elements may use a lot of smart cards that are inherently limited in memory:

Table 1 Summary of Java card language restrictions

Language Features	Dynamic class loading, security management (Java. Lang. securitymanager), threads, object cloning, and some aspects of package access control are not supported.
Keywords	Native, synchronized, transient, volatile, and strictfp are not supported.
Type	Char, double, float, and long are not supported, and multi-dimensional arrays are not supported. Int support is optional.
Class and Interface	Java Core Application Programming Interface classes and interfaces (Java. Io, java. Lang, java. util) except for object and throwable are not supported, and most methods of object and throwable are unavailable.
Exception	Some exception and error subclasses are omitted because the exceptions and errors encapsulated by them cannot appear on the Java card platform.

 

There are also restrictions on the program model. For example, a library class can no longer be extended to the card; it implicitly becomes the final type.

To meet storage restrictions, the jcvm Specification defines additional constraints on many program attributes. Table 4 jcvm resource limits. Note that many of these constraints are clear to Java card developers.

Table 2 Summary of Java card VM Constraints

 

Package	One package can reference 128 other packages
	A fully qualified package name is limited to 255 bytes. Note that the character size depends on the character encoding.
	A fully qualified package name is limited to 255 bytes.
Class	A class can directly or indirectly implement up to 15 interfaces.
	An interface can inherit a maximum of 14 interfaces.
	If a package contains a small application (a small application package), it can have a maximum of 256 static methods; if there is no small application (library package ), it can have up to 255 static methods.
	A class can support up to 128 public or protected instance methods.

 

In Java card virtual machines, class files are the core, just like in j2se virtual machines, but jcvm standards define two other file formats to further make the platform independent, convert the converted applet (CAP) and export (export) formats.Article.

Virtual Machine Lifecycle 

The lifecycle of jcvm is the same as that of the card itself: After the card is manufactured and tested, it starts the lifecycle for a period of time before it is released to the card holder, when a card is lost or destroyed, its lifecycle ends. When a card has no power, jcvm will not stop because its status is saved in non-volatile memory of the card. Start jcvm to initialize jcres and create all jcres framework objects, which are running throughout the jcvm lifecycle. After jcvm is started, the interaction with the card is in principle controlled by a small application on the card. When the card has no power, any data stored in Ram will be lost, but any State stored in permanent memory will be retained. After power-on again, the virtual machine is activated again, and the status of the Virtual Machine and object is restored, and the execution starts again, waiting for further input.