JavaCard简介(中文版)
JavaCard和Native之比较
社保；
PSAM或者ESAM；
Key卡；
USBKey。
案例数量
数量逐步增加，突出表现在借贷记应用领域、新业务领域和复合应用领域。
已经广泛的应用在一些传统的领域，或者有一定历史的项目中。
容量和价格
EEPROM空间大小
通常为20K，36K，72K或者更大，便于对于多应用的支持
通常为8K,16K或者32K,36K，便于节约成本，大批量展开。
RSA密钥长度支持
按照JavaCardAPI接口V2.2.1，支持512，736，768，896，1024，1280，1536，1984，2048位长度的密钥。
可以支持芯片所能支持的按8字节或者4字节长度递增的密钥长度。
协作开发
可以开发一种特殊的Applet，作为可以被其他应用Applet调用的通用的功能模块(Library)，以便于统一提供一些功能的实现。
添加全新的指令
对相应的Applet源代码进行单独的修改，不影响其他应用的实现和稳定性，不影响底层的JavaCard平台的实现和稳定性。
只需要对修改的Applet进行测试和认证。
对卡片操作系统（COS）进行修改，可能会影响其他应用的指令的实现和稳定性。
需要重新进行整体的测试和认证。
不同应用下，相同的指令支持不同功能
由于卡片EEPROM空间通常小一些，所以价格相对比较便宜。
开发一个全新的Applet应用。不影响其他应用的实现和稳定性，不影响底层的JavaCard平台的实现和稳定性。
只需要对新增的Applet进行测试和认证。
对卡片操作系统（COS）进行修改，增加新的应用和交易。可能会影响其他应用的指令的实现和稳定性。
需要重新进行整体的测试和认证。
Java Card CAP文件分析
Java Card CAP文件分析JAVA卡的可执行文件（CAP 文件）是编译多个应用程序（Applet）的生成结果，包含了一个包中定义的所有类和接口，与包之间是一一对应的关系。
实际发卡操作时，首先需要将该可执行文件下载至卡片中，并安装需要的应用实例；用户使用该安装的应用实例执行操作功能。
CAP文件包含12个组件：注意：一个完整的CAP文件，除COMPONET_Applet、COMPONET_Export 和COMPONET_Debug组件是可选外，其他均为必选。
每个组件封装成一个CAP包，包含在Jar包中。
最后在卡上只保留了5个组件：COMPONET_Method，COMPONET_Class，COMPONET_ConstantPool，COMPONET_StaticField和COMPONET_Export。
其余的组件只是安装时提取有用信息而不在卡中保存。
12个组件中，类class组件保存本应用声明的所有类和接口的信息；方法method 组件保存本应用声明的所有方法和接口，method中利用2字节索引index引用类、方法和域；常数池constant pool组件保存method组件引用的所有类、方法和域信息，分为类、实例域、虚方法、父方法、静态域和静态方法6类，每组信息为4个字节；相关地址reference location组件保存method组件中索引的偏移。
对于Java Card而言，应用程序的下载过程是即CAP文件写入到EEPROM的过程，即是对CAP文件的下载过程。
在CAP文件的下载过程中，需要将一部分组件进行解析，同时对reference location中指定的位置进行链接，能够链接到method 组件中的一个索引号，并根据索引号查找constant pool中保存的、与该索引号对应的类、方法或域在EEPROM中的实际地址，调用实际地址中存储的数据。
也就是说，方法的调用其实是需要两个步骤来实现的：1.根据reference location中指定的位置进行链接，获取method组件中的索引号；2.根据索引号查找constant pool中保存的、与该索引号对应的类、方法或域在EEPROM中的实际地址，调用实际地址中存储的数据。
JavaCardApplet开发讲义
本手册的版权和解释权属于握奇数据系统有限公司
4
4
本手册的版权和解释权属于握奇数据系统有限公司
2
JavaCard Applet开发讲义
握奇数据
JavaCard VM的限制
JavaCard VM规范额外定义了一些程序属性的约束。 Java Card开发者 要注意这些约束。
程序包
一个程序包可以引用128个其他的程序包
在同一个执行上下文中的小应用程序默认情况下能够相
互访问，所以Applet A和Applet B不需要遵循这个程序 来共享对象。
Applet A
①
Applet B
JCRE
②
Applet C
Applet D applet firewall
本手册的版权和解释权属于握奇数据系统有限公司
12
12
本手册的版权和解释权属于握奇数据系统有限公司
Applet A Applet B
Applet C
Applet D applet firewall
JCRE
本手册的版权和解释权属于握奇数据系统有限公司
11
11
握奇数据
Applet的隔离与共享
Java Card平台支持跨防火墙的安全对象共用。典型的 流程如下：
– 请求通过调用系统的JCSystem.getAppletSharea bleInterfaceObject ()方法访问Appletc的共享接
Java Card事务以对beginTransaction()的调用开始，以对 commitTransaction()或者abortTransaction()的调用结束。在事务过 程中所有的写操作都将被保护。JCRE不支持嵌套事务。
Java Card平台虚拟机规范（经典版）v3.2说明书
Java Card™Platform Virtual Machine Specification, Classic EditionVersion 3.2January 2023Java Card Platform Virtual Machine Specification, Classic Edition Version 3.2Copyright © 1998, 2023, Oracle and/or its affiliates. All rights reserved.The Specification provided herein is provided to you only under the Oracle Technology Network Developer License included herein as Annex A - Oracle Technology Network Developer License Terms.License Restrictions Warranty/Consequential Damages DisclaimerThis software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.Warranty DisclaimerThe information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.Restricted Rights NoticeIf this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.Hazardous Applications NoticeThis software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.Trademark NoticeOracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.Third-Party Content, Products, and Services DisclaimerThis software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.Documentation AccessibilityFor information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at /pls/topic/lookup?ctx=acc&id=docacc.Access to Oracle SupportOracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit /pls/topic/lookup?ctx=acc&id=info or visit/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.ContentsPreface (19)Who Should Use This Specification (19)Before You Read This Specification (19)Shell Prompts (19)Typographic Conventions (20)Related Documentation (20)Third-Party Web Sites (20)Documentation Accessibility (21)Access to Oracle Support (21)Oracle Welcomes Your Comments (21)1Introduction (22)1.1 Motivation (22)1.2 The Java Card Virtual Machine (23)1.3 Java Language Security (25)1.4 Java Card Runtime Environment Security (25)2 A Subset of the Java Virtual Machine (27)2.1 Why a Subset is Needed (27)2.2 Java Card Platform Language Subset (27)2.2.1 Unsupported Items (27)2.2.1.1 Unsupported Features (27)2.2.1.1.1 Dynamic Class Loading (27)2.2.1.1.2 Security Manager (28)2.2.1.1.3 Finalization (28)2.2.1.1.4 Threads (28)2.2.1.1.5 Cloning (28)2.2.1.1.6 Access Control in Java Packages (28)2.2.1.1.7 Typesafe Enums (28)2.2.1.1.8 Enhanced for Loop (29)2.2.1.1.10 Runtime Visible Metadata (Annotations) (29)2.2.1.1.11 Assertions (29)2.2.1.2 Unsupported Keywords (29)2.2.1.3 Unsupported Types (29)2.2.1.4 Unsupported Classes (29)2.2.1.4.1 System (30)2.2.2 Supported Items (30)2.2.2.1 Supported Features (30)2.2.2.1.1 Packages (30)2.2.2.1.2 Dynamic Object Creation (30)2.2.2.1.3 Virtual Methods (30)2.2.2.1.4 Interfaces (30)2.2.2.1.5 Exceptions (30)2.2.2.1.6 Generics (31)2.2.2.1.7 Static Import (31)2.2.2.1.8 Runtime Invisible Metadata (Annotations) (31)2.2.2.2 Supported Keywords (31)2.2.2.3 Supported Types (32)2.2.2.4 Supported Classes (32)2.2.2.4.1 Object (32)2.2.2.4.2 Throwable (32)2.2.3 Optionally Supported Items (32)2.2.3.1 Integer Data Type (33)2.2.3.2 Object Deletion Mechanism (33)2.2.4 Limitations of the Java Card Virtual Machine (33)2.2.4.1 Limitations of Packages (33)2.2.4.1.1 Packages in a Java Card CAP file (33)2.2.4.1.2 Package References (33)2.2.4.1.3 Package Name (33)2.2.4.2 Limitations of Classes (34)2.2.4.2.1 Classes in a Package (34)2.2.4.2.3 Static Fields (34)2.2.4.2.4 Static Methods (34)2.2.4.3 Limitations of Objects (34)2.2.4.3.1 Methods (34)2.2.4.3.2 Class Instances (34)2.2.4.3.3 Arrays (34)2.2.4.4 Limitations of Methods (34)2.2.4.5 Limitations of Switch Statements (35)2.2.4.6 Limitations of Class Initialization (35)2.2.5 Multiselectable Applets Restrictions (35)2.2.6 Java Card Platform Remote Method Invocation (RMI) Restrictions (35)2.2.6.1 Remote Classes and Remote Interfaces (36)2.2.6.2 Access Control of Remote Interfaces (36)2.2.6.3 Parameters and Return Values (36)2.3 Java Card VM Subset (36)2.3.1 Class File Subset (37)2.3.1.1 Not Supported in Class Files (37)2.3.1.1.1 Class Access Flags (37)2.3.1.1.2 Field Descriptors (37)2.3.1.1.3 Constant Pool (37)2.3.1.1.4 Fields (37)2.3.1.1.5 Methods (37)2.3.1.2 Supported in Class Files (37)2.3.1.2.1 ClassFile (37)2.3.1.2.2 Field Descriptors (37)2.3.1.2.3 Method Descriptors (38)2.3.1.2.4 Constant Pool (38)2.3.1.2.5 Fields (38)2.3.1.2.6 Methods (38)2.3.1.2.7 Attributes (38)2.3.2 Bytecode Subset (38)2.3.2.2 Supported Bytecodes (40)2.3.2.3 Static Restrictions on Bytecodes (42)2.3.2.3.1 ldc, ldc_w (42)2.3.2.3.2 lookupswitch (42)2.3.2.3.3 tableswitch (42)2.3.2.3.4 wide (42)2.3.3 Exceptions (43)2.3.3.1 Uncaught and Uncatchable Exceptions (43)2.3.3.2 Checked Exceptions (43)2.3.3.3 Runtime Exceptions (44)2.3.3.4 Errors (44)3Structure of the Java Card Virtual Machine (46)3.1 Data Types and Values (46)3.2 Words (46)3.3 Runtime Data Areas (47)3.4 Contexts (47)3.5 Frames (47)3.6 Representation of Objects (48)3.7 Special Initialization Methods (48)3.8 Exceptions (48)3.9 Binary File Formats (48)3.10 Instruction Set Summary (48)3.10.1 Types and the Java Card Virtual Machine (49)4Binary Representation (51)4.1 Java Card Platform File Formats (51)4.1.1 Export File Format (51)4.1.2 CAP File Format (52)4.1.3 JAR File Container (52)4.2 AID-based Naming (53)4.2.1 The AID Format (53)4.2.2 AID Usage (53)4.2.2.2 Applet AID namespace (53)4.2.2.3 Package AID namespace (54)4.2.2.3 Custom Component AID namespace (54)4.3 Token-based Linking (54)4.3.1 Externally Visible Items (54)4.3.2 Private Tokens (55)4.3.3 The Export File and Conversion (55)4.3.4 References – External and Internal (55)4.3.5 Installation and Linking (56)4.3.6 Token Assignment (56)4.3.7 Token Details (56)4.3.7.1 Package (56)4.3.7.2 Classes and Interfaces (56)4.3.7.3 Static Fields (57)4.3.7.4 Static Methods and Constructors (57)4.3.7.5 Instance Fields (57)4.3.7.6 Virtual Methods (58)4.3.7.7 Interface Methods (58)4.4 Binary Compatibility (59)4.5 CAP and Package Versions (60)4.5.1 Assigning (60)4.5.2 Linking (60)5The Export File Format (62)5.1 Export File Name (62)5.2 Containment in a JAR File (62)5.3 Ownership (62)5.4 Hierarchies Represented (63)5.5 Export File (63)5.6 Constant Pool (65)5.6.1 CONSTANT_Package (65)5.6.2 CONSTANT_Classref (67)5.6.4 CONSTANT_Utf8 (68)5.7 Classes and Interfaces (68)5.8 Fields (71)5.9 Methods (73)5.10 Attributes (75)5.10.1 ConstantValue Attribute (75)6The CAP File Format (77)6.1 CAP File Overview (77)6.2 Component Model (78)6.2.1 Containment in a JAR File (79)6.2.2 Defining New Components (80)6.3 Installation (81)6.4 Header Component (81)6.5 Directory Component (85)6.6 Applet Component (90)6.7 Import Component (92)6.8 Constant Pool Component (93)6.8.1 CONSTANT_Classref (95)6.8.2 CONSTANT_InstanceFieldref, CONSTANT_VirtualMethodref, CONSTANT_SuperMethodref (96)6.8.3 CONSTANT_StaticFieldref and CONSTANT_StaticMethodref (98)6.9 Class Component (100)6.9.1 type_descriptor (102)6.9.2 interface_info, class_info_compact and class_info_extended (104)6.9.2.1 interface_info, class_info_compact and class_info_extended Shared Items (105)6.9.2.2 interface_info Items (106)6.9.2.3 class_info_compact and class_info_extended Items (107)6.9.2.4 method_block_info (111)6.9.2.5 implemented_interface_info (112)6.9.2.6 remote_interface_info (113)6.9.2.7 public_virtual_method_token_mapping (115)6.10 Method Component (116)6.10.1 method_component_block (117)6.10.2 Exception Handler Example (118)6.10.3 exception_handler_info (119)6.10.4 method_info (121)6.11 Static Field Component (123)6.12 Reference Location Component (127)6.12.1 reference_location_component_block (128)6.13 Export Component (130)6.14 Descriptor Component (133)6.14.1 package_descriptor_info (135)6.14.2 class_descriptor_info_compact and class_descriptor_info_extended (135)6.14.3 field_descriptor_info (137)6.14.4 method_descriptor_info_compact and method_descriptor_info_extended (139)6.14.5 type_descriptor_info (142)6.15 Debug Component (143)6.15.1 package_debug_info_compact and package_debug_info_extended Structures (145)6.15.2 The class_debug_info_compact and class_debug_info_extended Structures (145)6.15.2.1 The field_debug_info Structure (148)6.15.2.2 The method_debug_info_compact and method_debug_info_extended Structures (150)6.16 Static Resource Component (154)7Java Card Virtual Machine Instruction Set (157)7.1 Assumptions: The Meaning of “Must” (157)7.2 Reserved Opcodes (157)7.3 Virtual Machine Errors (157)7.4 Security Exceptions (158)7.5 The Java Card Virtual Machine Instruction Set (159)7.5.1 aaload (160)7.5.2 aastore (161)7.5.3 aconst_null (163)7.5.4 aload (163)7.5.5 aload_<n> (164)7.5.6 anewarray (165)7.5.8 arraylength (166)7.5.9 astore (166)7.5.10 astore_<n> (167)7.5.11 athrow (168)7.5.12 baload (169)7.5.13 bastore (169)7.5.14 bipush (170)7.5.15 bspush (171)7.5.16 checkcast (171)7.5.17 dup (173)7.5.18 dup_x (174)7.5.19 dup2 (175)7.5.20 getfield_<t> (175)7.5.21 getfield_<t>_this (176)7.5.22 getfield_<t>_w (178)7.5.23 getstatic_<t> (179)7.5.24 goto (180)7.5.25 goto_w (181)7.5.26 i2b (181)7.5.27 i2s (182)7.5.28 iadd (182)7.5.29 iaload (183)7.5.30 iand (184)7.5.31 iastore (184)7.5.32 icmp (185)7.5.33 iconst_<i> (186)7.5.34 idiv (186)7.5.35 if_acmp<cond> (187)7.5.36 if_acmp<cond>_w (188)7.5.37 if_scmp<cond> (189)7.5.38 if_scmp<cond>_w (189)7.5.40 if<cond>_w (191)7.5.41 ifnonnull (192)7.5.42 ifnonnull_w (193)7.5.43 ifnull (193)7.5.44 ifnull_w (194)7.5.45 iinc (194)7.5.46 iinc_w (195)7.5.47 iipush (195)7.5.48 iload (196)7.5.49 iload_<n> (197)7.5.50 ilookupswitch (197)7.5.51 imul (198)7.5.52 ineg (199)7.5.53 instanceof (200)7.5.54 invokeinterface (202)7.5.54.1 Interface Method Resolution (203)7.5.55 invokespecial (204)7.5.56 invokestatic (205)7.5.56.1 Super Method Resolution (206)7.5.57 invokevirtual (206)7.5.57.1 Virtual Method Resolution (207)7.5.58 ior (208)7.5.59 irem (208)7.5.60 ireturn (209)7.5.61 ishl (210)7.5.62 ishr (210)7.5.63 istore (211)7.5.64 istore_<n> (211)7.5.65 isub (212)7.5.66 itableswitch (213)7.5.67 iushr (214)7.5.69 jsr (215)7.5.70 new (216)7.5.71 newarray (216)7.5.72 nop (217)7.5.73 pop (218)7.5.74 pop2 (218)7.5.75 putfield_<t> (219)7.5.76 putfield_<t>_this (220)7.5.77 putfield_<t>_w (222)7.5.78 putstatic_<t> (223)7.5.79 ret (224)7.5.80 return (225)7.5.81 s2b (225)7.5.82 s2i (226)7.5.83 sadd (226)7.5.84 saload (227)7.5.85 sand (228)7.5.86 sastore (228)7.5.87 sconst_<s> (229)7.5.88 sdiv (229)7.5.89 sinc (230)7.5.90 sinc_w (231)7.5.91 sipush (231)7.5.92 sload (232)7.5.93 sload_<n> (232)7.5.94 slookupswitch (233)7.5.95 smul (234)7.5.96 sneg (234)7.5.97 sor (235)7.5.98 srem (235)7.5.99 sreturn (236)7.5.101 sshr (237)7.5.102 sspush (238)7.5.103 sstore (238)7.5.104 sstore_<n> (239)7.5.105 ssub (239)7.5.106 stableswitch (240)7.5.107 sushr (241)7.5.108 swap_x (241)7.5.109 sxor (242)8Tables of Instructions (244)8.1 Instructions by Opcode Value (244)8.2 Instructions by Opcode Mnemonic (248)Glossary (254)Annex A - Oracle Technology Network Developer License Terms (269)FiguresFigure 1-1: Java Card Application or Library Conversion (23)Figure 1-2: Java Card Application or Library Installation (24)Figure 4-1: Mapping Package Identifiers to AIDs (54)Figure 4-2: Binary Compatibility Example (59)TablesTable 2-1: Unsupported Java Constant Pool Tags (37)Table 2-2: Supported Java Constant Pool Tags (38)Table 2-3: Support of Java Checked Exceptions (43)Table 2-4: Support of Java Runtime Exceptions (44)Table 2-5: Support of Java Errors (44)Table 3-1: Type Support in the Java Card Virtual Machine Instruction Set (49)Table 3-2: Storage Types and Computational Types (50)Table 4-1: AID Format (53)Table 4-2: Token Range, Type and Scope (56)Table 4-3: Tokens For Instance Fields (57)Table 5-1: Export File Constant Pool Tags (65)Table 5-2: Export File Package Flags (66)Table 5-3: Export File Class Access and Modifier Flags (69)Table 5-4: Export File Field Access and Modifier Flags (72)Table 5-5: Export File Method Access and Modifier Flags (74)Table 6-1: CAP File Component Tags (79)Table 6-2: CAP File Component File Names (79)Table 6-3: CAP File Flags (83)Table 6-4: CAP File Constant Pool Tags (94)Table 6-5: Type Descriptor Values (102)Table 6-6: Encoded Reference Type p1.c1 (103)Table 6-7: Encoded Byte Array Type (103)Table 6-8: Encoded Reference Array Type p1.c1 (103)Table 6-9: Encoded Method Signature ()V (104)Table 6-10: Encoded Method Signature (Lp1.ci;)S (104)Table 6-11: CAP File Interface and Class Flags (106)Table 6-12: CAP File Method Flags (122)Table 6-13: Segments of a Static Field Image (124)Table 6-14: Static Field Sizes (124)Table 6-15: Array Types (126)Table 6-16: One-byte Reference Location Example (129)Table 6-17: CAP File Class Descriptor Flags (136)Table 6-18: CAP File Field Descriptor Flags (138)Table 6-19: Primitive Type Descriptor Values (139)Table 6-20: CAP File Method Descriptor Flags (140)Table 6-21: Class Access and Modifier Flags (146)Table 6-22: Field Access and Modifier Flags (149)Table 6-23: Method Modifier Flags (151)Table 7-1: Example Instruction Entry (159)Table 7-2: Array Values (172)Table 7-3: Array Values (200)Table 7-4: Array Values (217)Table 8-1: Instructions by Opcode Value (244)Table 8-2: Instructions by Opcode Mnemonic (248)PrefaceJava Card technology combines a subset of the Java programming language with a runtime environment optimized for secure elements, such as smart cards and other tamper-resistant security chips. Java Card technology offers a secure and interoperable execution platform that can store and update multiple applications on a single resource-constrained device, while retaining the highest certification levels and compatibility with standards. Java Card developers can build, test, and deploy applications and services rapidly and securely. This accelerated process reduces development costs, increases product differentiation, and enhances value to customers.The Classic Edition of the Java Card Platform is defined by three specifications:∙Virtual Machine Specification, Java Card Platform, Version 3.2, Classic Edition,∙Runtime Environment Specification, Java Card Platform, Version 3.2, Classic Edition,∙Application Programming Interface, Java Card Platform, Version 3.2, Classic Edition.This document is a specification of the Classic Edition of the Java Card Platform, Version 3.2, Virtual Machine (Java Card VM).In this book, Java Card Platform refers to version 3.2 to distinguish it from all earlier versions. A vendor of a Java Card technology-enabled device provides an implementation of the Java Card RE. An implementation within the context of this specification refers to a vendor's implementation of the Java Card Virtual Machine (or Java Card VM), the Java Card Application Programming Interface (API), or other component, based on the Java Card technology specifications. A "reference implementation" is an implementation produced by Oracle. Application software written for the Java Card platform is referred to as a Java Card technology-based applet (Java Card applet or card applet).Who Should Use This SpecificationThis specification is intended to assist implementers of the Java Card RE in creating an implementation, developing a specification to extend the Java Card technology specifications, or in creating an extension to the runtime environment for the Java Card platform. This specification is also intended for Java Card applet developers who want a greater understanding of the Java Card technology specifications.Before You Read This SpecificationBefore reading this guide, you should be familiar with the Java programming language, the other Java Card technology specifications, and smart card technology. A good resource for becoming familiar with Java technology and Java Card technology located at:/technetwork/java/javacard/overview/Shell PromptsShell PromptC shell machine-name%C shell superuser machine-name#Bourne shell and Korn shell $Bourne shell and Korn shell superuser #Typographic ConventionsThe settings on your browser might differ from these settings. Typeface Meaning ExamplesAaBbCc123 The names of commands,files, and directories; on-screen computer output Edit your .login file. Use ls -a to list all files. % You have mail.AaBbCc123 What you type, whencontrasted with on-screen computer output %su Password:AaBbCc123 Book titles, new words orterms, words to beemphasized. Replacecommand-line variableswith real names orvalues. Read Chapter 6 in the User's Guide. These are called class options. You must be superuser to do this. To delete a file, type rm filename.Related DocumentationReferences to various documents or products are made in this guide, so you might want to have them available:∙Application Programming Interface, Java Card Platform, Version 3.2, Classic Edition∙Runtime Environment Specification, Java Card Platform, Version 3.2, Classic Edition∙The Java Language Specification (https:///javase/specs/)∙ISO 7816 Specification Parts 1-6. (https://)Third-Party Web SitesOracle is not responsible for the availability of third-party web sites mentioned in this document. Oracle does not endorse and is not responsible or liable for any content, advertising, products, or other materials that are available on or through such sites or resources. Oracle will not be responsible or liable for any actual or alleged damage or loss caused by or in connection with the use of or reliance on any such content, goods, or services that are available on or through such sites or resources.Documentation AccessibilityFor information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at:/pls/topic/lookup?ctx=acc&id=docacc.Access to Oracle SupportOracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit:/pls/topic/lookup?ctx=acc&id=infoOr, if you are hearing impaired, visit:/pls/topic/lookup?ctx=acc&id=trsOracle Welcomes Your CommentsOracle is interested in improving its documentation and welcomes your comments and suggestions.Please include the title of your document with your feedback:Virtual Machine Specification, Java Card Platform, v3.2, Classic Edition1IntroductionThis document specifies the Java Card Virtual Machine features required by the Classic Edition ofJava Card technology.∙It defines the subset of the Java Virtual Machine used for the Java Card Virtual Machine and list the supported and unsupported features.∙It defines the binary representation of the application code, the role and structure of the Export and CAP file formats and their use in the verification and linking process.∙It specifies the Java Card Virtual Machine byte-code set and its detailed behavior.1.1 MotivationJava Card technology enables programs written in the Java programming language to be run on secure elements such as smart cards and other tamper-resistant security chips. Developers can build and test programs using standard software development tools and environments, then convert them into a form that can be installed onto a Java Card technology-enabled device. Application software for the Java Card platform is called an applet, or more specifically, a Java Card applet (to distinguish it from browser applets).While Java Card technology enables programs written in the Java programming language to run on small devices such as smart cards, those are far too under-powered to support the full functionality of the Java platform. Therefore, the Java Card platform supports only a carefully chosen, customized subset of the features of the Java platform. This subset provides features that are well-suited for writing programs for small devices and preserves the object-oriented capabilities of the Java programming language.A simple approach to specifying a Java Card virtual machine would be to describe the subset of the features of the Java virtual machine that must be supported to allow for portability of source code across all Java Card technology enabled devices. Combining that subset specification and the information in Java Virtual Machine Specification, smart card and secure elements manufacturers could construct their own Java Card technology-based implementations (“Java Card implementations”). While that approach is feasible, it has a serious drawback. The resultant platform would be missing the important feature of binary portability of Java Card applets.The standards that define the Java platform allow for binary portability of Java programs across all Java platform implementations. This “write once, run anywhere” quality of Java programs is perhaps the most significant feature of the platform. Part of the motivation for the creation of the Java Cardplatform was to bring just this kind of binary portability to the embedded security and smart card industry. In a world with billions of secure elements with varying processors and configurations, the costs of supporting multiple binary formats for software distribution could be overwhelming.This Virtual Machine Specification, Java Card Platform, v3.2, Classic Edition is the key to providing binary portability. One way of understanding what this specification does is to compare it to its counterpart in the Java platform. The Java virtual machine specification defines a Java virtual machine as an engine that loads Java class files and executes them with a particular set of semantics. The class file is a central piece of the Java architecture, and it is the standard for the binary compatibility of the Java platform. The Virtual Machine Specification, Java Card Platform, v3.2, Classic Edition also defines a file format that is the standard for binary compatibility for the Java Card platform: the CAP file format is the form in which software is deployed to be loaded onto devices which implement a Java Card virtual machine.1.2 The Java Card Virtual MachineThe role of the Java Card virtual machine is best understood in the context of the process for production and deployment of software for the Java Card platform. There are several components that make up a Java Card system, including the Java Card virtual machine, the Converter for the Java Card platform (“Java Card Converter”), a terminal installation tool, and an installation program that runs on the device, as shown in Figure 1-1 and Figure 1-2.Figure 1-1: Java Card Application or Library ConversionFigure 1-2: Java Card Application or Library InstallationDevelopment of a Java Card applet begins as with any other Java program: a developer writes one or more Java classes, and compiles the source code with a Java compiler, producing one or more class files. The applet is run, tested and debugged on a workstation using simulation tools to emulate the device environment. Then, when an applet is ready to be downloaded to a device, the class files comprising the applet are converted to a CAP (converted applet) file using a Java Card Converter.The Java Card Converter takes as input all of the class files in one or more Java packages which make up a Java Card CAP file. A Java package that contains one or more non-abstract subclasses, direct or indirect, of the javacard.framework.Applet class is referred to as an applet package. Otherwise the package is referred to as a library package. A Java Card CAP file may contain only applet packages, only library packages or a combination of applet and library packages. Additionally, both applet and library packages in a Java Card CAP file can be public or private.A private library package in a Java Card CAP file is not listed in the Export Component (6.13 Export Component) of the CAP file and is therefore not visible outside the Java Card CAP file. Similarly, a private applet package in a Java Card CAP file is not listed in the Export Component (6.13 Export Component) of the CAP file, however, non-abstract direct or indirect subclasses of thejavacard.framework.Applet class are listed in the Applet Component (6.6 Applet Component) of the CAP file. For a public applet package in a Java Card CAP file, only public interfaces extending javacard.framework.Shareable are listed in the Export Component (6.13 Export Component) of the CAP file and are therefore visible outside the Java Card CAP file. For further details see The CAP File Format.The Java Card Converter also takes as input one or more export files. An export file contains name and link information for the contents of other packages that are imported by the classes being converted. The converter can also produce export files for the public applet and library packages in a CAP file.After conversion, the CAP file is copied to a terminal, such as a desktop computer with a card reader peripheral. Then an installation tool on the terminal loads the CAP file and transmits it to the Java Card technology-enabled device. An installation program on the device receives the contents of the CAP file。
JavaCard简介(中文版)
1、简介Java Card 3 平台由两个版本组成Classic Edition和Connected Edition：Classic Edition是一个基于 2.2.2版本的前端兼容的演化平台，针对资源有限的设备仅支持applet-based应用。
如果你只对Classic Edition中提供的功能感兴趣的话就可以忽略Connected Edition。
Connected Edition提供了一个显著增强的运行时环境和一个新的虚拟机。
包含了一些新的面向网络的应用，例如提供了针对web应用的Servlet APIs，并且支持一些新的applet功能增强。
一个Connected Edition的应用可能会用到Classic Edition提供的特性，因此这两个版本的规范应用一起使用。
1.1动机Java Card技术使得用Java编程语言编写的程序可以运行在智能卡和其他小的资源紧张的设备上。
开发人员可以用标准的软件开发工具和环境来编译和调试程序，然后把程序转化成能被Java Card支持的格式。
Java Card上的应用程序被称为Applet，或者更明确的称为Java Card Applet 或者Card Applet（为了和浏览器Applets做区分）。
Java Card技术使得用Java语言编写的程序可以在智能卡上运行，然而如此小的设备远不足以支持Java平台的全部功能。
因此，Java Card平台仅仅支持一个被仔细挑选，定制的Java平台属性的的子集。
这个子集使得写的程序在小设备上有更好适应性，并且保持了Java语言的面向对象的特性。
一个简单的途径是定义一个代码可以在所有Java Card环境下移植的Java虚拟机的子集。
结合JVM的子集规定和信息，智能卡提供商可以在Java Card规范上构建自己的工具。
虽然手段是可行的，但有一个严重的缺点，目标平台将会丧失字节码的移植性。
Java平台的规范允许Java的代码在所有Java平台上移植，Java的“写一次，所有地方运行”的属性或许是平台的最重要的特性。
java说明文档中文版
java说明文档中文版篇一：java说明文档中文版Java SE Platform 软件包java.applet 提供创建applet 所必需的类和applet 用来与其applet 上下文通信的类。
java.awt 包含用于创建用户界面和绘制图形图像的所有类。
java.awt.color 提供用于颜色空间的类。
java.awt.datatransfer 提供在应用程序之间和在应用程序内部传输数据的接口和类。
java.awt.dnd Drag 和Drop 是一种直接操作动作，在许多图形用户界面系统中都会遇到它，它提供了一种机制，能够在两个与GUI 中显示元素逻辑相关的实体之间传输信息。
java.awt.event 提供处理由AWT 组件所激发的各类事件的接口和类。
java.awt.font 提供与字体相关的类和接口。
java.awt.geom 提供用于在与二维几何形状相关的对象上定义和执行操作的Java 2D 类。
java.awt.im 提供输入方法框架所需的类和接口。
java.awt.im.spi 提供启用可以与Java 运行时环境一起使用的输入方法开发的接口。
java.awt.image 提供创建和修改图像的各种类。
java.awt.image.renderable 提供用于生成与呈现无关的图像的类和接口。
java.awt.print 为通用的打印API 提供类和接口。
java.beans 包含与开发beans 有关的类，即基于JavaBeansTM 架构的组件。
java.beans.beancontext 提供与bean 上下文有关的类和接口。
java.io 通过数据流、序列化和文件系统提供系统输入和输出。
ng 提供利用Java 编程语言进行程序设计的基础类。
ng.annotation 为Java 编程语言注释设施提供库支持。
ng.instrument 提供允许Java 编程语言代理检测篇二：java说明文档中文版JA VA开发人员必备是CHM格式的，中文版，就是详细介绍java（j2se平台）系统包，类库的文档JavaTM 2 Platform Standard Edition 6API 规范本文档是Java 2 Platform Standard Edition 6.0 的API 规范。
GP卡片规范_v2JavaCard中文
GlobalPlatform卡片规范版本2.22006年5月目录1 介绍 (7)1.1 受众 (8)1.2 标准参考规范 (8)1.3 术语及定义 (10)1.4 缩写和符号 (13)2 系统架构 (17)3 卡片架构 (18)3.1 安全域 (18)3.2 全局服务应用 (19)3.3 运行时环境 (19)3.4 可信任框架 (19)3.5 GlobalPlatform环境(OPEN) (19)3.6 GlobalPlatform API (20)3.7 卡片内容 (20)3.8 卡片管理器 (20)4 安全架构 (21)4.1 目标 (21)4.2 安全职责和要求 (21)4.2.1 发卡方的职责 (21)4.2.2 应用提供方的职责 (22)4.2.3 授权管理者的职责 (22)4.2.4 卡片组件的安全性要求 (22)4.2.4.1 运行时环境的安全性要求 (22)4.2.4.2 可信任框架的安全性要求 (22)4.2.4.3 OPEN的安全性要求 (22)4.2.4.4 安全域的的安全性要求 (23)4.2.4.5 全局服务应用的安全性要求 (23)4.2.4.6 应用的安全性要求 (23)4.2.5 后台系统的安全性要求 (23)4.3 加密支持 (23)4.3.1 安全的卡片内容管理 (24)4.3.1.1 加载文件数据块散列值 (24)4.3.1.2 加载文件数据块签名(DAP) (24)4.3.1.3 委托管理令牌 (24)4.3.1.4 收条 (24)4.3.2 安全通信 (24)5 生命周期模型 (27)5.1 卡片生命周期 (27)5.1.1 卡片生命周期状态 (27)5.1.1.1 卡片生命周期状态OP_READY (27)5.1.1.2 卡片生命周期状态INITIALIZED (28)5.1.1.3 卡片生命周期状态SECURED (28)5.1.1.4 卡片生命周期状态CARD_LOCKED (28)5.1.1.5 卡片生命周期状态TERMINATED (28)5.1.2 卡片生命周期状态的迁移 (28)5.2 可执行加载文件和可执行模块生命周期 (29)5.2.1 可执行加载文件生命周期 (29)5.2.1.1 Executable Load Life Cycle LOADED (29)5.2.1.2 可执行加载文件的删除 (30)5.2.2 可执行模块的生命周期 (30)5.3 应用和安全域的生命周期 (30)5.3.1 应用生命周期状态 (30)5.3.1.1 应用生命周期状态INSTALLED (30)5.3.1.2 应用生命周期状态SELECTABLE (31)5.3.1.3 应用生命周期状态LOCKED (31)5.3.1.4 应用的删除 (31)5.3.1.5 应用自定义的生命周期状态 (31)5.3.1.6 应用生命周期状态的迁移 (31)5.3.2 安全域生命周期状态 (32)5.3.2.1 安全域生命周期状态INSTALLED (32)5.3.2.2 安全域生命周期状态SELECTABLE (33)5.3.2.3 安全域生命周期状态PERSONALIZED (33)5.3.2.4 安全域生命周期状态LOCKED (33)5.3.2.5 安全域的删除 (33)5.3.2.6 安全域生命周期状态的迁移 (33)5.4 生命周期图解 (34)6 GlobalPlatform环境(OPEN) (36)6.1 综述 (37)6.2 OPEN服务 (38)6.3 命令分发 (38)6.4 逻辑通道和应用选择 (39)6.4.1 隐式选择的分派 (39)6.4.2 基本逻辑通道 (39)6.4.2.1 基本逻辑通道的应用选择 (39)6.4.2.1.1 基本逻辑通道上应用的隐式选择 (39)6.4.2.1.2 基本逻辑通道上应用的显式选择 (40)6.4.2.2 基本逻辑通道上的逻辑通道管理 (41)6.4.2.3 基本逻辑通道上的应用命令分发 (41)6.4.3 补充逻辑通道 (41)6.4.3.1 补充逻辑通道的应用选择 (41)6.4.3.1.1 补充逻辑通道上应用的隐式选择 (42)6.4.3.1.2 补充逻辑通道上应用的显式选择 (42)6.4.3.2 补充逻辑通道上的逻辑通道管理 (43)6.4.3.3 补充逻辑通道上的应用命令分发 (43)6.5 GlobalPlatform注册表 (43)6.5.1 应用/可执行加载文件/可执行模块等数据元素 (44)6.5.1.1 应用/可执行加载文件/可执行模块的AID (44)6.5.1.2 应用/可执行加载文件/可执行模块的生命周期 (44)6.5.1.3 内存资源管理参数 (44)6.5.1.4 权限 (44)6.5.1.5 隐式应用选择参数 (44)6.5.1.6 关联安全域的AID (44)6.5.1.7 应用提供方ID (44)6.5.1.8 服务参数 (44)6.5.2 卡片级数据 (45)6.6 权限 (45)6.6.1 权限定义 (45)6.6.2 权限分配 (46)6.6.3 权限管理 (47)6.7 GlobalPlatform可信任框架 (47)7 安全域 (49)7.1 概要描述 (49)7.1.1 发卡方安全域 (49)7.2 关联到安全域 (50)7.3 安全域服务 (51)7.3.1 应用对安全域服务的访问 (51)7.3.2 安全域对应用的访问 (52)7.3.3 个人化支持 (52)7.3.4 运行时消息的支持 (53)7.4 安全域数据 (54)7.4.1 发卡方安全域 (54)7.4.1.1 发卡方标识编号 (54)7.4.1.2卡片映像编号 (55)7.4.1.3 卡片标识数据 (55)7.4.2 补充安全域 (55)7.4.2.1 安全域提供方标识编号 (55)7.4.2.2 安全域映像编号 (55)7.4.2.3 安全域管理数据 (55)7.5 安全域密钥 (56)7.5.1 密钥信息 (56)7.5.2 密钥访问条件 (56)7.6 数据和密钥管理 (57)8 全局平台服务 (58)8.1 全局服务应用 (58)8.1.1 注册全局服务 (58)8.1.2 应用对全局服务的访问 (58)8.1.3 全局服务参数 (59)8.2 持卡方验证方法(CVM)应用 (59)8.2.1 应用对CVM服务的访问 (60)8.2.2 CVM管理 (60)8.2.2.1 注册CVM (60)8.2.2.2 CVM状态 (60)8.2.2.2.1 CVM状态ACTIVE (61)8.2.2.2.2 CVM状态INV ALID_SUBMISSION (61)8.2.2.2.3 CVM状态V ALIDATED (61)8.2.2.2.4 CVM状态BLOCKED (61)8.2.2.3 CVM格式 (61)9 卡片和应用的管理 (62)9.1 卡片内容管理 (62)9.1.1 概述 (62)9.1.2 对OPEN的要求 (62)9.1.3 对安全域的要求 (63)9.1.3.1 具备“令牌验证权限”的安全域 (63)9.1.3.2 具备“授权管理权限”的安全域 (63)9.1.3.3 具备“委托管理权限”的安全域 (63)9.1.3.4 具备“全局删除权限”的安全域 (63)9.1.3.5 具备“全局锁定权限”的安全域 (63)9.1.3.6 具备“收条创建权限”的安全域 (64)9.2 卡片内容的授权和管理 (64)9.2.1 数据鉴别(DAP)模式验证 (64)9.2.2 加载文件数据块的散列值 (64)9.2.3 令牌 (64)9.3 卡片内容的加载、安装和可选择化 (64)9.3.1 概述 (64)9.3.2 卡片内容的加载 (65)9.3.3 卡片内容的安装 (66)9.3.4 卡片内容的加载、安装和可选择化联合操作 (66)9.3.5 卡片内容加载过程 (66)9.3.6 卡片内容的安装过程 (69)9.3.7 卡片内容的可选择化过程 (70)9.3.8 卡片内容的加载、安装和可选择化联合操作过程 (71)9.3.9 加载和安装流程的示例 (73)9.4 内容的让渡和注册表的更新 (76)9.4.1 内容的让渡 (76)9.4.2 注册表的更新 (78)9.4.2.1 普通的注册表更新 (78)9.4.2.2 注册表更新中的让渡操作 (79)9.5 内容的删除 (80)9.5.1 应用删除 (81)9.5.2 可执行加载文件的删除 (82)9.5.3 可执行加载文件和相关应用的删除 (83)9.6 安全管理 (85)9.6.1 生命周期管理 (85)9.6.2 应用的锁定和解锁 (85)9.6.3 卡片的锁定和解锁 (86)9.6.4 卡片终结 (87)9.6.5 应用状况的查询 (88)9.6.6 卡片状况的查询 (88)9.6.7 操作的频度检测 (88)9.6.7.1 内容加载和安装 (88)9.6.7.2 异常 (89)9.6.8 跟踪和事件日志 (89)9.7 内存资源管理 (89)10 安全通信 (90)10.1 安全通信 (91)10.2 显式和隐式安全通道 (91)10.2.1 显式安全通道的开启 (91)10.2.2 隐式安全通道的开启 (91)10.2.3 安全通道的终止 (91)10.3 安全通道协议的直接处理和间接处理 (92)10.4 实体认证 (92)10.4.1 对称加密算法下的认证 (92)10.4.2 非对称加密下的认证 (92)10.5 安全的消息传送 (93)10.6 安全级别 (93)10.7 安全通道协议标识符 (93)第一部介绍1 介绍GlobalPlatform是一家由支付和通信业的领先厂商、政府相关部门以及供应商社区共同建立的一个组织，并率先提出了一个跨行业的智能卡全局基础架构及其实现，其目标是为了减少隐藏在快速增长的跨行业、多应用的智能卡背后的障碍，使得发卡商在各种各样的卡片、终端和后台系统前，继续享有选择的自由。
java card标准
java card标准
Java Card是Java的一个子集，专为智能卡等资源受限设备设计。
其以Java Card Platform specifications（爪哇卡平台规格）为依循标准，此技术规格标准由升阳电脑所研发。
Java Card的主要特点及诉求在于移携性与安全性。
在语言级别，Java Card的所有语言结构都存在于Java中并且行为相同。
这意味着Java Card程序能被Java编译器编译成Java类文件，类文件由特定于Java Card平台的工具进行后续的处理。
但是Java Card 不支持许多Java语言功能，例如char、double、float和long类型，以及对象的finalization、对象克隆等。
此外，Java Card的字节码是由Java Card虚拟机运行的Java Card 字节码，是标准Java虚拟机运行的Java字节码的功能子集，但具有不同的编码以优化大小。
与通过编译相同Java源代码获得的Java小程序相比，Java Card小程序通常使用更少的字节码。
这节省了内存，这是资源受限设备（如智能卡）的必需品。
同时，作为设计权衡，不支持某些Java语言功能和大小限制。
存在克服大小限制的技术，例如将应用程序的代码分成低于64K限制的包。
以上内容仅供参考，建议查阅关于java card标准的资料获取更全面和准确的信息。
JavaCard开发教程之入门篇
JavaCard开发教程之规范多年以前，Sun微系统公司实现了智能卡和类似的资源约束设备的潜能，并且定义了一组Java技术子集规范来为它们创建应用程序，Java Card小应用程序。
支持这些规范的设备称为Java Card平台。
在一个Java Card平台上，来自不同的供应商的多个应用程序可以安全地共存。
一个典型的Java Card设备有一个8或16位的运行在3.7MHz的中央处理器，带有1K 的RAM和多于16K的非易失性存储器(可编程只读存储器或者闪存）。
高性能的智能卡带有单独的处理器和加密芯片，以及用于加密的内存，并且有一些还带有32位的中央处理器。
Java Card技术规范目前是2.2版，由三部分组成：·Java Card虚拟机规范，定义了用于智能卡的Java程序语言的一个子集和虚拟机。
·Java Card运行时环境规范，进一步定义了用于基于Java的智能卡的运行期行为。
·Java Card应用编程接口规范，定义了用于智能卡应用程序核心框架和扩展Java程序包和类。
Sun还提供了Java Card开发工具箱(JCDK) /products/javacard/，包含了Java Card运行期环境和Java Card虚拟机的引用实现，和其它帮助开发Java Card 小应用程序的工具。
本文的第二部分将详细讲述JCDK。
Java Card技术和J2ME平台让我们比较一下Java Card和J2ME平台技术：图. Java Card技术和J2ME平台CDC和CLDC配置以及它们JavaCard开发教程之程序元素完整的Java Card应用程序由一个后端应用程序和系统、一个主机（卡外）应用程序、一个接口设备（读卡器）和卡上小应用程序、用户证书和支持软件组成。
所有的这些元素共同组成一个安全的端到端应用程序：图1. Java Card应用程序的体系结构一个典型的Java Card应用程序不是孤立的，而是包含卡端、读取端和后端元素。
JAVA卡技术概述
JA V A卡技术概述---------------------------------------------------------------------------------------------------------------------- 编辑整理：编辑:王鹏来源：门禁关键字：JA V A爪哇卡（JavaCard）技术可使以爪哇语言所写成的程序，在智能卡和其它资源受限装置上执行。
本文将让您一览爪哇卡技术，包括该系统的结构和组件。
本概述的目的在让您对爪哇卡技术有一个整体性了解，并介绍有关爪哇卡系统的重点和基本概念，以利程序开发者设计程序之用。
一、爪哇卡技术之组件爪哇卡技术包括下列部分：＊精简后之爪哇程序语言以及适合智能卡应用的虚拟机（JavaCardVirtualMachine,JCVM）定义＊核心之爪哇卡应用程序接口（ApplicationProgrammingInterface,API）及其延伸部分＊爪哇卡之执行时期环境（JavaCardRuntimeEnvironment,JCRE）爪哇卡应用程序接口和执行时期环境是以智能卡工业标准ISO7816为模型而设计，因此，爪哇卡平台可轻易支持跟ISO7816第一到第六部分兼容的智能卡系统和应用。
爪哇卡应用程序被称为applets。
爪哇卡平台可支持多重应用（multiapplication）环境。
爪哇卡应用程序则是在爪哇之执行时期环境内处理和执行。
二、精简之爪哇卡语言若智能卡的程序可使用爪哇程序语言的所有功能写成当然最好，不过对智能卡和其它资源受限装置来说，由于运算资源有限，要完全支持爪哇程序语言是不可能也不切实际的事。
一般智能卡是以1K的随机存取内存（RAM），以及16K的非挥发性内存（EEPROM或RAM）和24K的只读存储器（ROM）规格出现，因此，爪哇卡平台仅能支持经小心选取且已规格化而有精简功能的爪哇语言。
此精简爪哇语言包含之功能，适于设计智能卡以及其它小型装置的程序，同时还能保留爪哇程序语言以对象为导向（object－oriented）的能力。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1、简介Java Card 3 平台由两个版本组成Classic Edition和Connected Edition：Classic Edition是一个基于 2.2.2版本的前端兼容的演化平台，针对资源有限的设备仅支持applet-based应用。
如果你只对Classic Edition中提供的功能感兴趣的话就可以忽略Connected Edition。
Connected Edition提供了一个显著增强的运行时环境和一个新的虚拟机。
包含了一些新的面向网络的应用，例如提供了针对web应用的Servlet APIs，并且支持一些新的applet功能增强。
一个Connected Edition的应用可能会用到Classic Edition提供的特性，因此这两个版本的规范应用一起使用。
1.1动机Java Card技术使得用Java编程语言编写的程序可以运行在智能卡和其他小的资源紧张的设备上。
开发人员可以用标准的软件开发工具和环境来编译和调试程序，然后把程序转化成能被Java Card支持的格式。
Java Card上的应用程序被称为Applet，或者更明确的称为Java Card Applet 或者Card Applet（为了和浏览器Applets做区分）。
Java Card技术使得用Java语言编写的程序可以在智能卡上运行，然而如此小的设备远不足以支持Java平台的全部功能。
因此，Java Card平台仅仅支持一个被仔细挑选，定制的Java平台属性的的子集。
这个子集使得写的程序在小设备上有更好适应性，并且保持了Java语言的面向对象的特性。
一个简单的途径是定义一个代码可以在所有Java Card环境下移植的Java虚拟机的子集。
结合JVM的子集规定和信息，智能卡提供商可以在Java Card规范上构建自己的工具。
虽然手段是可行的，但有一个严重的缺点，目标平台将会丧失字节码的移植性。
Java平台的规范允许Java的代码在所有Java平台上移植，Java的“写一次，所有地方运行”的属性或许是平台的最重要的特性。
部分Java Card平台创建的工作就是为了把这种代码移植性带到智能卡行业。
在世界上有千百万的不同处理器和配置的智能卡，为支持软件派发所支持的多种代码格式的代价是不能承受的。
这个Java Card的虚拟机规范（版本3.0.1Classic Edition)是提供代码移植性的关键。
理解这个规范做了什么的一个方法是和Java平台的对应副本进行比较。
Java虚拟机规范定义了一个引导和按指令集执行Java类文件的引擎。
类文件是Java体系结构里面核心的部分，并且是代码移植性的支柱。
Java Card的虚拟机规范（版本3.0.1Classic Edition）仍然定义了一个实现了Java Card平台代码移植性的文件格式：CAP文件格式是软件被导入到实现了Java Card虚拟机规范的设备的格式。
1.2The Java Card Virtual MachineJava Card虚拟机的角色在Java Card平台的生产和开发流程下很好理解。
Java Card虚拟机和若干个组件组成一个Java Card系统，一个Converter(转换器),一个终端安装工具，和一个运行在设备上的安装程序。
如下图1-1和1-2。
开发一个Java Card应用和开发其它的Java程序一样：一个开发者写出一个或者多个类文件，应用使用模拟设备环境的模拟器模拟运行，测试和调试，包含应用的类文件被Java Card Coverter 转化成一个CAP文件。
Converter把构成一个Java包的所有类作为输入。
一个包含了一个或者多个非抽象的直接或者非直接的javacard.framework.Applet的子类的包被称作一个应用包(appet package)。
否则被称为一个库包（library package)。
Converter也可以把一个或者多个导出文件（export file）作为输入。
一个导出文件包含了被转化类需要的导入的其它类的名字和链接信息。
当一个应用或者库包被转化，转化器也可以产生这个包的导出文件。
经过转化，CAP文件被拷贝到一个卡片终端，例如一个带有读卡器设备的桌面计算机。
然后一个在终端上的安装工具载入CAP文件并且传输到Java Card设备里。
一个存在于Java Card设备上的安装程序接收CAP文件的内容并且准备好被Java Card虚拟机运行的应用。
虚拟机自己不需要导入或者操作CAP文件，它只需要执行在被安装程序导入的CAP文件中发现的应用的代码。
Java Card虚拟机和安装程序工程的区分使得两者都更小，安装程序可以被实现为一个Java程序并且在Java Card虚拟机的上层执行。
因为Java虚拟机的指令比典型的机器码更稠密，这样做可以降低安装器的大小。
组件性可以使得在一个Java Card虚拟机实现上可以使用不同的安装器。
1.3Java Language Security一个Java虚拟机的基本属性是通过类文件校验实现的强大的安全性。
许多实现了Java Card 平台的设备可能太小不足以支持在自己设备上的校验。
这个考虑使得设计上允许在设备上认证但是并不信赖它。
CAP文件中校验相关的数据被和应用执行的真正数据分开放置。
到允许安全管理更灵活的被实现。
在Java Card设备上有几个提供语言级别安全的选项。
概念上最简单的是在CAP文件下载时和下载后验证文件内容。
这个选项通常在比较大的设备上可行。
其它的选项信赖一些捆绑的属性：安全终端的物理安全，在下载时候的算法校验过程，在下载之前预校验CAP文件。
Java Card平台规范在CAP文件安装和安全规则这儿尽量的少说。
因为智能卡在不同的安全需求的不同系统里作为安全的处理器，有必要允许很多灵活性来适应智能卡发行人和用户。
1.4Java Card Runtime Environment SecurityJava Card平台的标准运行环境叫做JCRE，JCRE由Java Card虚拟机以及Java Card API 的类构成，既然Java Card虚拟机有保证Java语言层安全的责任，JCRE保证附加的运行态的安全。
这部分的附加属性在JCRE规范中。
JCRE最基本的运行态安全特性是用一个应用防火墙把应用隔离开。
应用防火墙阻止一个应用创建的对象被其它的应用访问，阻止了对未授权的实例的属性和方法的访问（访问数组的长度类似）。
应用的隔绝是一个重要的安全属性，但是它需要一个机制来允许应用间在需要内部操作的时候共享对象。
JCRE允许使用共享接口对象（shareable interface object）的概念来进行这样的共享。
这些对象提供了一个应用让它的对象可能被其他应用使用的唯一的方式。
更多的使用共享接口对象的信息参见API手册中javacard.framework.Shareable接口的描述。
一些防火墙相关的属性的描述为共享接口提供了一定的参考。
应用防火墙还避免了对JCRE自身拥有的对象的未授权使用。
JCRE可以使用不在JCAPI中体现的机制使得它的对象可以被应用使用。
JCRE隔离和共享的相关属性可以在JCRE规范中得到体现。
2、A Subset of the Java Virtual Machine2.1 Why a Subset is Needed典型的卡片设备只有1.2K的RAM，16K的非易失性存储（EEPROM or flash）以及32K-48K 的ROM。
2.2 Java Card Platform Language SubsetJava Card平台的Applets用Java语言编写并用Java编译器编译。
Java Card技术应用Java语言的一个子集。
2.2.1 Unsupported Items2.2.1.1 Unsupported FeaturesDynamic Class Loading ,Security Manager ,Finalization ,Threads ,Cloning ,Access Control in Java Packages ,Typesafe Enums ,Enhanced for Loop ,Varargs ,Runtime Visible Metadata (Annotations) ,Assertions.2.2.1.2 Unsupported KeywordsNative, synchronized, transient , volatile ,strictfp , enum ,assert.2.2.1.3 Unsupported Typeschar, double, float, long,arrays of more than one dimension.2.2.1.4 C lasses总之，没有任何的Java语言核心API类在Java Card平台获得完全支持。
ng.package 包中的有些类得到支持而剩下的则不支持，例如不支持String, Thread类，以及像Boolean ,Integer这样的包装类。
SystemClass ng.System不被支持，Java Card平台提供javacard.framework.JCSystem 作为系统功能接口。
2.2.2 Supported Items如果一个语言特性没有被Java Card规范明确声明为不支持，那么它就属于支持子集的一部分，值得注意的支持特性在本节描述。
2.2.2.1 FeaturesPackages,Dynamic Object Creation,Virtual Methods, Interfaces, Exceptions, Generics, Static Import, Runtime Invisible Metadata (Annotations)2.2.2.2 Keywords2.2.2.3 TypesJava的类型boolean, byte, short, int是被支持的，Objects（类的实例和一维数组）也是支持的，数组可以包含被平台支持的原始数据类型，对象和其它数组。
有些java Card实现可能不支持int类型。
2.2.2.4 Classes大部分ng package中的类在java Card平台中不被支持。
下面的ng中的类被有限的支持。
Object同Java语言一样，java Card平台API类继承于ng.Object，类Object中的大部分方法都无法使用，但是Object本身被作为继承系统的根得以保留。
Throwable类Throwable和它的子类得以支持。