java-card 介绍

Java Card 3 is a major evolution of the current Java Card 2 platform. While Java Card 3 enhances the classic interoperability, security, and multiple-application support in the platform, it exploits such new hardware features as more memory, more processing power, and enhanced communication capabilities. In this way, Java Card 3 comprises both the Classic Edition and a new Connected Edition.

 

 

Java card 技术简介

The smart cards that were introduced in the 1980s had a single chip in every card, with very limited resources (especially RAM). The dominant smart card technology today runs on 4 to 8 Kb of RAM and 32 to 64 Kb of EEPROM, using slow 8-bit processors, and uses a very limited subset of Java that provides

• Partial support of basic types (8/16-bit values, no float, no String)
• Small subset of Java ME APIs
• Specific, pre-processed binary file formats
• Single threading (no garbage collection)

 

 

Figure 1: The smart chip in a card

 

 

Java Card 3 extends the Java Card 2 support for classic applets into improved connected features targeting less resource-constrained devices and including new network-oriented features.

The following figure shows the high-level architecture for Java Card 3.

下图是java card 的技术体系结构图 

Figure 2: Java Card 3 architecture

 

 

When deploying web applications, Java Card deployment is the same as the standard web application format, with no lib folder.

Java Card 3 runs on the recent high-end smart cards, which have more memory (approximately 24K of Volatile and 128K of Non-Volatile) and a fast 32-bit processor.

Java Card 3 also offers full Java language support, including support for

• All data types except float and double
• Multiple threads
• Extensive API support ( java.lang, java.util, GCF, and so on)
• Direct handling of class files, with all loading and linking on card
• All new Java language syntax constructs, like enums, generics, enhanced for loops, auto boxing/unboxing, and so on
• Automatic garbage collection

The new connectivity layers and protocol stack features promise support for the emerging technology in the coming years, as shown in Figure 3.

 

Figure 3: Connectivity layers and protocol stack

 

 

Java Card 开发步骤

 

Java Card 3.0 Compared with Java SE
There are three main differences between Java Card 3.0 and Java SE.

• First, Java Card applications do not have main() method, so the application start does not use main() method.
  • Java Card applications use the lifecycle model.
  • Applet Container and Servlet Container are supported.
  • Application components are either Java Card applets or servlets.
• Network programming uses GCF API as opposed to the java.net framework, which is too large for Java Cards.
  • Connector.open("http://.....");
  • Connector.open("socket://host:1234");
• Finally, Java Card does not support the entire Java SE API .

Java Card 3.0 Compared with Java ME
Java Card 3.0 is very close to the Java ME Connected Limited Device Configuration (CLDC).

• Class files are compiled with JDK 6 (class file major version is 5.0)
• Class File Verification is the same as in CLDC
  • But no preverifier, because JDK 6 generates StackMapTables
  • JDK 6 Stackmaps are a little different than preverifier-generated Stackmaps, but the purpose is same
• Java Card does not use MIDlets, but Java Card applets and servlets
• JAD file of a Java ME MIDlet suite can be compared to Java Card Runtime Descriptor

Java Card 3.0 Compared with Java EE
There are several similarities in functionality, since Java Card 3 supports a web server application model much like Java EE. For example,

• Java Card provides a servlet container with full servlet lifecycle support.
• WAR file format is supported with Java Card 3.0 specific information, like Java Card Runtime Descriptor.
• Transactions using annotations are supported by Java Card, with @ TransactionSupport(TransactionSuportType.REQUIRED)
• Per-application Secure Sockets Layer (SSL) protocol support is new in Java Card 3.0
• One area that is not quite like the full Java EE is that there is no JSP support, just servlets (and static HTML) with listeners and filters.

 

Reference Implementation (RI)

As part of the Java Card Development Kit, a Reference Implementation (RI) will be available, with support for both classic and connected functionality. It will contain the following:

• Card emulator
• Tools to build and deploy an application or servlets:
  • Off-card installer
  • Packager
  • Converter
  • Normalizer
• Introductory how-to samples
• Documentation

 

A NetBeans IDE plugin will also be available at the time of the release — more about that in the following sections.

Creating the "Hello" App Using the RI
The reference implementation will include the usual "hello, world" application, as shown in the following code.

 

Figure 4: Reference Implementation code

 

 

Compiling and Packaging the Code
The easiest way to compile the Java source code and build the app is to use the NetBeans IDE. The manual steps from source code to putting the application on the card — the tool chain — are shown in the following figure. The NetBeans IDE automates many of these steps.

 

Figure 5: Packaging the application

 

 

As shown Figure 5, to compile the source code, you can use the javac compiler to compile the source code, and so on. If you use the NetBeans IDE plugin, it will handle the compilation and the packaging. The NetBeans IDE Packager tool can be used to create the final module file from a folder. It also can be used to validate pre-shipped application modules or WAR files.

Loading and Creating the Application Module
Deployment is a two-step process. First you load the module onto a card. Then you create a persistent instance of the loaded module. You can use the off-card installer to load the Application module and to create the instance. You can then use your browser to view the page.

Deleting and Unloading the Application Module
If the application is no longer needed on the card, it can be removed completely in a two-step process. Use Delete to remove any given persistent instance of the application. Then use Unload to completely remove all class files and related resource files from the card.

You can use the off-card installer to delete the application instance and to unload the application.