Features of java operating system

Introduction:

When 1st java card details were issued, the card chips where 8 bits with a few hundred of bytes of RAM and a few kilo bytes of EEPROM. These sever constraints led the java card forum and Sun to issue a had lots of limitations compared to standard java.

This specification does not specify and operating system but an execution environment that most player in the smart card industry is able to implement on top of his own proprietary operating system. The silicon market evolution seems to indicate that next generation products will be based on much more powerful machines (32bits, 64bits, RISC, cache are becoming common in chip category) the smart card industry, through the java card forum, has clearly indentified this evolution and has started initiatives like the java card 3.0 details process that aim to define upcoming version of java card adapted nest era of hardware with this hardware evolution, java has also evolved a lot. It is more limited to the desktop environment and is now present in both the server market with J2EE and in the embedded system market with J2ME.

This evolution brought interesting feature to the java platform process for running long lived application are popular on the server side and less java subset applicable to categories of devices has been defined with J2ME configuration.

The purpose of this assignment is to have overview of what can be considered now as the less java feature that can be integrated to modern smart card hardware and how these features that can be integrated to modern smart card hardware and how these features can be turned into a card operating system that cope with the smart card industry particular constraint like big production, personalization post issuance. The reason for targeting an operating system instead of an additional software layer like it’s done in the computer world with standard JDK is to use java as the unique hardware abstraction for applications without intermediate levels to reduce the workload and increase the efficiency.

Features of Java Operating System:

The java platform defined in different techniques the java VM (Virtual Machine) specification and the java language specification. In the context of operating system these techniques are only relevant at the running environment level. The selection of the java Operating System features is guided by the classical needs of OS. The coding, linking, running engine and memory management for the performance.

Class file of Java:

The class file is Java define in the JVM (Java Virtual Machine) specification as delivery format for the code of classed to load into a Java VM. This format is considered to be verbose and not compact, but it has some other properties that provide a maximum flexibility both for the development and for the code application update. Other formats such as the Java card 2.x Cap file or the JEFF file format are focusing on reducing file size using the command and techniques like linking information removal or file structure reorganization. These techniques have good result in size reduction but induce deployment constraints depending on the degree of size reduction for example a Cap file can be ten percent size of the equivalent set of class files, but it requires an off card conversion step for the developer and to maintain off card a database of linking information to perform card pre linking which is painful work for deployment and card management.

We argue that on card class file processing that provides the same reduction ration as the JEFF conversion fifty percent reduction. The process explaining more detail in figure below.

Since the load link operation occurs only once in the life times on the class, we think that the development benefits brought by loading standard class files are worth the effort of loading the class file in its entirety and applying an on board conversion process that enable to store in card memory a structure equivalent to fifty percent of the original class file size.

One of the main industrial profits of choosing the class file and defining you own conversion process is that it gives freedom for differentiation most of the card manufacture can choose an internal format adapted to his own particular constraints.

Engine Multithreaded Execution:

the java platform has native support for multithreaded and synchronization and even in the lowest configuration defined for the embedded system market like CLDC, this help to maintained the one may think that for embedded and resource constrained devices the

Support for the multithreading may be too heavy to be reasonable, well there are lots of reason to have multithreading support in the core of very small java operating system. The core reason is that it enables to write power application framework on top of the Operating System, in java without needing complex native modifications of the Operating System and it’s happen when the SIM Toolkit application model has been explained in java card. There are also lots of classical reasons to use threads that are briefly described in the literature.

In limited devices like smart cards, memory such as the Virtual Machine implements must be carefully choose an efficient and resource helping implementation of the multithreading support. The existence of java application only on the top of java operating system collaborating with native code and not with native application like in a desktop computer seems to support a green thread like implementation rather than a native thread implementation.

Java Memory Management:

One of the interesting feature of Java Virtual Machine (JVM) is the automatically garbage collected heap that is used to allocate java objects when they are created, letting the burden of moving, compacting, freeing the memory to the system instead of the developer.

This interesting feature was lacking in the java card specification and give the developer of complex applications to developer their own memory management routines within the application code, which is written in java, this disadvantage of java card to behave as an Operating System. The programs shouldn’t handle such sensitive task. There are several types of garbage collectors but the ones that seem the more appropriate to smart card like environments are generational collector. This type of collector are well adapted to server like long lived application which is typically the case of smart card program.

Actually the memory manage for the object instances is separate from the memory management of system data like description, threads, code, classes, objects. This normally leading toward the complexity, bigger footprint of the memory management and static segmentation of the memory. We are experimenting an alternative to such a split organization that is to use unified object oriented memory management and static segmentation of the memory. We are experimenting an alternative to such a split organization that is to use a unified object oriented memory manager that both types of programs and system objects, in this case most of the things in the system is an object including java objects instances, loaded, code, classes and every object in the system is subject to garbage collection.

This memory management leads to easy management code which is then hopefully smaller and more robust.

Different Application Models:

Most of the earlier feature of the Java Virtual Machine (JVM) describe above have common objective put in the Operating System the functionality that will make smaller and more efficient application. One great strength of java that was lost in java card and that we think must be reconsidered for next generation smart card Operating System is to be application model independent. The Java Virtual Machine (JVM) doesn’t clarify a particular application model, but gives all the core features that are necessary to build various successful frameworks such as applets, serves or RMI Objects.

Configurations:

The smart card program and system designers and developers have considerations that are very similar to the people working in the mass production embedded system devices market. How to debugging fast/safely the Operating System and the programs, how to build quickly a product configuration, and how to decline and Operating System in product range to leverage the investment. There is more, the smart card industry has his own particularities like for instance the need for personalization of every issued card with the holder information.

Development Issues:

The use of java is in itself the beginning of a solution for some of these problems, because of the wide range of products freely or commercially available to help designers and developers. But the high safety exigency on smart card products implies that maximum effort must be made on any tools that would allow the developers to operate in an environment as close as possible to the actual device. Debugging the code while it runs.

Issues:

Product issue and other tools are help in the production and personalize phase of the cards. The ROM intervenes at the production step, to generate the code to mask into the chip’s ROM. It is complemented by the memory serialize which is used to build memory images saves in files. It will be sent to the card at initialization and personalize time to build the right memory structure that will put the card in the right state. Such tools are usually difficult to write and to maintain, but these tasks can be greatly simplified using the introspection capabilities provided by the unified object oriented memory management introduce above.

Integrated Operating System:

A solution to minimize the cost of these tools is to build an operating system that includes them from the beginning, in a configurable manner, and that can be declined from the same set of sources in different editions adapted to the targeted device. Such a configurable Operating System is illustrated in the following figure.

Feature Categories

Developer edition of the Operating System would include any developer features like an embedded debugging interface based on the JPDA standard, a shell based console to administer the Operating System load remove classes, create threads. Such a complete edition would of course run on computer and on emulator only not on real cards. Another declination would be the post issuance enabled edition that would be the high end embeddable version of the Operating System, targeted for high end cards with post issuance facilities with a loader linker. On the other eternity would be the minimal edition, targeted for low end cards, without any post issuance capabilities, that would have a much smaller footprint.

Conclusion:

In this assignment we have highlighted some features of an embedded java Operating System suitable for next generation smart cards considered as java micro server platforms. Three important java Operating System characteristic have been explained class file format acquisition, multithreaded support and unified memory management. Their implementation has been shown feasible and their usage and advantages has been explained in the context of configurable card platform architecture. Thanks to tools such shell console, debugger, ROMizer and Serialzier, the migration path from a rich platform configuration up to a customized platform configuration has been explained.

The overall advantages of this embedded java Operating System architecture is its adaptability for being used, on one hand as full fledge java environment to quickly develop and test programs and on the another hand as an engineering environment for mass production of optimized embedded code hosted by limited devices. Though originally developed in the context smart cards, such architecture could be suitable in any embedded system device in which the java development platform can different from the final Java deployment platform.

References:

[1] The Java Card Virtual Machine specification 2.1.1. Sun Microsystems

http://java.sun.com/products/javacard/

[2] Java 2 Micro Edition, Sun Microsystems

http://java.sun.com/j2me/

[3] Java Virtual Machine Specification,

Tim Lindholm, Frank Yellin. Sun Microsystems.

http://java.sun.com/docs/books/vmspec/index.html

[4] Java Language Specification,

James Gosling, Bill Joy, Guy Steele, Gilad Bracha. Sun Microsystems.

http://java.sun.com/docs/books/jls/index.html

[5] The JEFF File Format, J-Consortium

http://www.j-consortium.org/jeffwg/index.shtml

[5] J2ME Connected Limited Device Configuration

http://java.sun.com/products/cldc/

[6] Sim API for Java Card, ETSI TS 143 019 V5.2.0 (2002-03)

http://www.etsi.org

[7] Concurrent Programming in Java. D. Lea. Sun Microsystems, 1999.

ISBN 0-201-31009-0, Addison-Wesley

[8] Java Platform Debugger Architecture, Sun Microsystems,

http://java.sun.com/j2se/1.3/docs/guide/jpda/index.html

Master of Science BITE

Innovative Technology 1