Javacard development tutorial-Virtual Machine

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 program package access control are not supported.
keyword	native, synchronized, transient, volatile, and strictfp are not supported.
type	char, double, float, and long arrays are not supported. int support is optional.
classes and interfaces	JAVA Core Application Programming Interface classes and interfaces (Java. io, Java. lang, Java. 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 restrictions on the program model. for example, a library class cannot be extended to the card. It is implicitly final. 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 implement up to 15 interfaces directly or indirectly.
	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; without a small application (library package), it can have up to 255 static methods.
	A class can implement a maximum of 128 public or protected instance methods.

in Java card virtual machines, class files are the core, just like in j2se virtual machines, however, the jcvm Specification defines two other file formats to further make the platform independent and convert the formats of the converted applet (CAP) and the Export (export, this will be described later in the Article . virtual machine life cycle the jcvm life cycle is consistent with that of the card itself: after the card is manufactured and tested, it starts to have a life cycle when it is released to the cardholder's hand. When the card is lost or destroyed, its life cycle ends. when a card has no power, jcvm does 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, the virtual machine is activated again, and the status of the Virtual Machine and object is restored, and the task starts again, waiting for further input.