wiki javacard:jcvm

javacard:jcvm:1.1_motivation

2017-05-13T04:08:42+00:00

1.1 Motivation Java Card technology enables programs written in the Java programming language to be run on smart cards and other small, resource-constrained devices. 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 or card applet (to distingui…

javacard:jcvm:1.2_the_java_card_virtual_machine

2017-05-13T04:08:42+00:00

1.2 The Java Card Virtual Machine The 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 (

javacard:jcvm:1.3_java_language_security

2017-05-13T04:08:43+00:00

1.3 Java Language Security One of the fundamental features of the Java virtual machine is the strong security provided in part by the class file verifier. Many devices that implement the Java Card platform may be too small to support verification of CAP files on the device itself. This consideration led to a design that enables verification on a device but does not rely on it. The data in a CAP file that is needed only for verification is packaged separately from the data needed for the actual …

javacard:jcvm:1.4_java_card_runtime_environment_security

2017-05-13T04:08:44+00:00

1.4 Java Card Runtime Environment Security The standard runtime environment for the Java Card platform is the Java Card Runtime Environment. The Java Card RE consists of an implementation of the Java Card virtual machine along with the Java Card API

javacard:jcvm:1._introduction

2017-05-13T04:08:45+00:00

1. Introduction

javacard:jcvm:2.1_why_a_subset_is_needed

2017-05-13T04:08:45+00:00

2.1 Why a Subset is Needed It would be ideal if programs for smart cards could be written using all of the Java programming language, but a full implementation of the Java virtual machine is far too large to fit on even the most advanced resource-constrained devices available today.

javacard:jcvm:2.2.1.1_unsupported_features

2017-05-13T04:08:47+00:00

2.2.1.1 Unsupported Features Dynamic Class Loading Dynamic class loading is not supported in the Java Card platform. An implementation of the Java Card platform is not able to load classes dynamically. Classes are either masked into the card during manufacturing or downloaded through an installation process after the card has been issued. Programs executing on the card may only refer to classes that already exist on the card, since there is no way to download classes during the normal executio…

javacard:jcvm:2.2.1.2_keywords

2017-05-13T04:08:47+00:00

2.2.1.2 Keywords The following keywords indicate unsupported options related to native methods, threads, floating point, memory management, and debugging. native synchronized transient volatile strictfp enum assert

javacard:jcvm:2.2.1.3_unsupported_types

2017-05-13T04:08:48+00:00

2.2.1.3 Unsupported Types The Java Card platform does not support types char, double, float and long. It also does not support arrays of more than one dimension.

javacard:jcvm:2.2.1.4_classes

2017-05-13T04:08:48+00:00

2.2.1.4 Classes In general, none of the Java programming language core API classes are supported in the Java Card platform. Some classes from the java.lang package are supported (see Section 2.2.2.4, **Class**es), but none of the rest are. For example, classes that are not supported are

javacard:jcvm:2.2.1_unsupported_items

2017-05-13T04:08:50+00:00

2.2.1 Unsupported Items The items listed in this section are elements of the Java programming language and platform that are not supported by the Java Card platform.

javacard:jcvm:2.2.2.1_features

2017-05-13T04:08:50+00:00

2.2.2.1 Features Packages Software written for the Java Card platform follows the standard rules for the Java platform packages. Java Card API classes are written as Java source files, which include package designations. Package mechanisms are used to identify and control access to classes, static fields and static methods. Except as noted in

javacard:jcvm:2.2.2.2_keywords

2017-05-13T04:08:51+00:00

2.2.2.2 Keywords The following keywords are supported. Their use is the same as in the Java programming language. abstract default if private this boolean do implements protected throw break else import public throws byte extends

javacard:jcvm:2.2.2.3_types

2017-05-13T04:08:51+00:00

2.2.2.3 Types Java programming language types boolean, byte, short, and int are supported. Objects (class instances and single-dimensional arrays) are also supported. Arrays can contain the supported primitive data types, objects, and other arrays.

javacard:jcvm:2.2.2.4_classes

2017-05-13T04:08:53+00:00

2.2.2.4 Classes Most of the classes in the java.lang package are not supported on the Java Card platform. The following classes from java.lang are supported on the card in a limited form. Object Java Card API classes descend from java.lang.Object

javacard:jcvm:2.2.2_supported_items

2017-05-13T04:08:53+00:00

2.2.2 Supported Items If a language feature is not explicitly described as unsupported, it is part of the supported subset. Notable supported features are described in this section.

javacard:jcvm:2.2.3.1_integer_data_type

2017-05-13T04:08:54+00:00

2.2.3.1 Integer Data Type The int keyword and 32-bit integer data type need not be supported in a Java Card implementation. A Java Card virtual machine that does not support the int data type will reject programs which use the int data type or 32-bit

javacard:jcvm:2.2.3.2_object_deletion_mechanism

2017-05-13T04:10:00+00:00

2.2.3.2 Object Deletion Mechanism Java Card technology, version 2.2.2 offers an optional, object deletion mechanism. Applications designed to run on these implementations can use the facility by invoking the appropriate API. See Application Programming Interface, Java Card Platform, Version 2.2.2

javacard:jcvm:2.2.3_optionally_supported_items

2017-05-13T04:11:43+00:00

2.2.3 Optionally Supported Items This section describes the optional features of the Java Card platform. An optional feature is not required to be supported in a Java Card platform-compatible implementation. However, if an implementation does include support for an optional feature, it must be supported fully, and exactly as specified in this document.

javacard:jcvm:2.2.4.1_packages

2017-05-13T04:11:43+00:00

2.2.4.1 Packages Package References A package can reference at most 128 other packages. Package Name The fully qualified name of a package may contain a maximum of 255 characters. The package name size is further limited if it contains one or more characters which, when represented in UTF-8 format, requires multiple bytes.

javacard:jcvm:2.2.4.2_classes

2017-05-13T04:11:45+00:00

2.2.4.2 Classes Classes in a Package A package can contain at most 255 classes and interfaces. Interfaces A class can implement at most 15 interfaces, including interfaces implemented by superclasses. An interface can inherit from at most 14 superinterfaces.

javacard:jcvm:2.2.4.3_objects

2017-05-13T04:11:45+00:00

2.2.4.3 Objects Methods A class can implement a maximum of 128 public or protected instance methods, and a maximum of 128 instance methods with package visibility. These limits include inherited methods. Class Instances Class instances can contain a maximum of 255 fields, where an int data type is counted as occupying two fields. These limits include inherited fields.

javacard:jcvm:2.2.4.4_methods

2017-05-13T04:11:46+00:00

2.2.4.4 Methods The maximum number of variables that can be used in a method is 255. This limit includes local variables, method parameters, and, in the case of an instance method invocation, a reference to the object on which the instance method is being invoked (meaning,

javacard:jcvm:2.2.4.5_switch_statements

2017-05-13T04:11:46+00:00

2.2.4.5 Switch Statements The format of the Java Card virtual machine switch instructions limits switch statements to a maximum of 65536 cases. This limit is far greater than the limit imposed by the maximum size of methods ( Section 2.2.4.4, Methods).

javacard:jcvm:2.2.4.6_class_initialization

2017-05-13T04:11:48+00:00

2.2.4.6 Class Initialization The Java Card virtual machine contains limited support for class initialization because there is no general mechanism for executing methods. Support for methods is limited to the initialization of static field values with the following constraints:

javacard:jcvm:2.2.4_limitations_of_the_java_card_virtual_machine

2017-05-13T04:11:48+00:00

2.2.4 Limitations of the Java Card Virtual Machine The limitations of resource-constrained hardware prevent Java Card virtual machines from supporting the full range of functionality of certain Java platform features. The features in question are supported, but a particular virtual machine may limit the range of operation to less than that of the Java platform.

javacard:jcvm:2.2.5_multiselectable_applets_restrictions

2017-05-13T04:11:50+00:00

2.2.5 Multiselectable Applets Restrictions Applets that implement the javacard.framework.Multiselectable interface are called multiselectable applets. For more details on multiselection, please see the Runtime Environment Specification, Java Card Platform, Version 2.2.2

javacard:jcvm:2.2.6.1_remote_classes_and_remote_interfaces

2017-05-13T04:11:50+00:00

2.2.6.1 Remote Classes and Remote Interfaces A class is remote if it or any of its superclasses implements a remote interface. A remote interface is an interface which satisfies the following requirements: * The interface name is java.rmi.Remote

javacard:jcvm:2.2.6.2_access_control_of_remote_interfaces

2017-05-13T04:11:51+00:00

2.2.6.2 Access Control of Remote Interfaces The Java RMI system supports the package access control defined in the Java language. However, Java Card RMI does not support package-visible remote interfaces.

javacard:jcvm:2.2.6.3_parameters_and_return_values

2017-05-13T04:11:52+00:00

2.2.6.3 Parameters and Return Values The parameters of a remote method must only include parameters of the following types: * any primitive type supported by Java Card technology (boolean, byte, short, int), * any single-dimension array type of an primitive type supported by Java Card technology (

javacard:jcvm:2.2.6_java_card_platform_remote_method_invocation_rmi_restrictions

2017-05-13T04:11:53+00:00

2.2.6 Java Card Platform Remote Method Invocation (RMI) Restrictions This section defines the subset of the RMI system that is supported by Java Card platform RMI (“Java Card RMI”).

javacard:jcvm:2.2_java_card_platform_language_subset

2017-05-13T04:11:53+00:00

2.2 Java Card Platform Language Subset Applets written for the Java Card platform are written in the Java programming language. They are compiled using Java compilers. Java Card technology uses a subset of the Java language, and familiarity with the Java platform is required to understand the Java Card platform.

javacard:jcvm:2.3.1.1_not_supported_in_class_files

2017-05-13T04:11:54+00:00

2.3.1.1 Not Supported in Class Files Class access flags In class_info and interface_info structures_the access flag ACC_ENUM is not supported. Field Descriptors Field descriptors may not contain BaseType characters C, D, F or J. ArrayType descriptors for arrays of more than one dimension may not be used.

javacard:jcvm:2.3.1.2_supported_in_class_files

2017-05-13T04:11:55+00:00

2.3.1.2 Supported in Class Files ClassFile All items in the ClassFile structure are supported. Field Descriptors Field descriptors may contain BaseType characters B, I, S and Z, as well as any ObjectType. ArrayType descriptors for arrays of a single dimension may also be used.

javacard:jcvm:2.3.1_class_file_subset

2017-05-13T04:11:56+00:00

2.3.1 class File Subset The operation of the Java Card virtual machine can be defined in terms of standard Java platform class files. Since the Java Card virtual machine supports only a subset of the behavior of the Java virtual machine, it also supports only a subset of the standard class file format.

javacard:jcvm:2.3.2.1_unsupported_bytecodes

2017-05-13T04:11:57+00:00

2.3.2.1 Unsupported Bytecodes lconst_ fconst_ dconst_ ldc2_w2 lload fload dload lload_ fload_ dload_ laload faload daload caload lstore fstore dstore lstore_ fstore_ dstore_ lastore fastore dastore castore ladd fadd dadd lsub

javacard:jcvm:2.3.2.2_supported_bytecodes

2017-05-13T04:10:00+00:00

2.3.2.2 Supported Bytecodes nop aconst_null iconst_ bipush sipush ldc ldc_w iload aload iload_ aload_ iaload aaload baload saload istore astore istore_ astore_ iastore aastore bastore sastore pop pop2

javacard:jcvm:2.3.2.3_static_restrictions_on_bytecodes

2017-05-13T04:10:21+00:00

2.3.2.3 Static Restrictions on Bytecodes A class file must conform to the following restrictions on the static form of bytecodes. ldc_ldc_w The ldc and ldc_w bytecodes can only be used to load integer constants. The constant pool entry at index must be a

javacard:jcvm:2.3.2_bytecode_subset

2017-05-13T04:10:22+00:00

2.3.2 Bytecode Subset The following sections detail the bytecodes that are either supported or unsupported in the Java Card platform. For more details, refer to Chapter 7, “Java Card Virtual Machine Instruction Set”.

javacard:jcvm:2.3.3.1_uncaught_and_uncatchable_exceptions

2017-05-13T04:10:22+00:00

2.3.3.1 Uncaught and Uncatchable Exceptions In the Java platform, uncaught exceptions and errors will cause the virtual machine's current thread to exit. As the Java Card virtual machine is single-threaded, uncaught exceptions or errors will cause the virtual machine to halt. Further response to uncaught exceptions or errors after halting the virtual machine is an implementation-specific policy, and is not mandated in this document.

javacard:jcvm:2.3.3.2_checked_exceptions

2017-05-13T04:10:24+00:00

2.3.3.2 Checked Exceptions Exception Supported Not Supported ClassNotFoundException X CloneNotSupportedException X IllegalAccessException X InstantiationException X InterruptedException X NoSuchFieldException X NoSuchMethodException

javacard:jcvm:2.3.3.3_runtime_exceptions

2017-05-13T04:10:24+00:00

2.3.3.3 Runtime Exceptions Runtime Exception Supported Not Supported ArithmeticException X ArrayStoreException X ClassCastException X IllegalArgumentException X IllegalThreadStateException X NumberFormatException X

javacard:jcvm:2.3.3.4_errors

2017-05-13T04:10:25+00:00

2.3.3.4 Errors Error Supported Not Supported AssertionError X LinkageError X ClassCircularityError X ClassFormatError X ExceptionInInitializerError X IncompatibleClassChangeError X AbstractMethodError X IllegalAccessError

javacard:jcvm:2.3.3_exceptions

2017-05-13T04:10:26+00:00

2.3.3 Exceptions The Java Card platform provides full support for the Java platform's exception mechanism. Users can define, throw and catch exceptions just as in the Java platform. The Java Card platform also makes use of the exceptions and errors defined in The Java Language Specification. An updated list of the Java platform's exceptions is provided in the JDK software documentation.

javacard:jcvm:2.3_java_card_vm_subset

2017-05-13T04:10:27+00:00

2.3 Java Card VM Subset Java Card technology uses a subset of the Java virtual machine, and familiarity with the Java platform is required to understand the Java Card virtual machine. The items discussed in this section are not described to the level of a virtual machine specification. For complete documentation on the Java virtual machine, refer to the The Java Virtual Machine Specification.

javacard:jcvm:2._a_subset_of_the_java_virtual_machine

2017-05-13T04:10:27+00:00

2. A Subset of the Java Virtual Machine This chapter describes the subset of the Java virtual machine and language that is supported in the Java Card platform, Version 2.2.2.

javacard:jcvm:3.1_data_types_and_values

2017-05-13T04:10:30+00:00

3.1 Data Types and Values The Java Card virtual machine supports the same two kinds of data types as the Java virtual machine: primitive types and reference types. Likewise, the same two kinds of values are used: primitive values and reference values

javacard:jcvm:3.2_words

2017-05-13T04:10:30+00:00

3.2 Words The Java Card virtual machine is defined in terms of an abstract storage unit called a word. This specification does not mandate the actual size in bits of a word on a specific platform. A word is large enough to hold a value of type byte,

javacard:jcvm:3.3_runtime_data_areas

2017-05-13T04:10:31+00:00

3.3 Runtime Data Areas The Java Card virtual machine can support only a single thread of execution. Any runtime data area in the Java virtual machine which is duplicated on a per-thread basis will have only one global copy in the Java Card virtual machine.

javacard:jcvm:3.4_contexts

2017-05-13T04:10:32+00:00

3.4 Contexts Each applet running on a Java Card virtual machine is associated with an execution context. The Java Card virtual machine uses the context of the current frame to enforce security policies for inter-applet operations. There is a one-to-one mapping between contexts and packages in which applets are defined. An easy way to think of a context is as the runtime equivalent of a package, since Java packages are compile-time constructs and have no direct representation at runtime. As a …

javacard:jcvm:3.5_frames

2017-05-13T04:10:33+00:00

3.5 Frames Java Card virtual machine frames are very similar to those defined for the Java virtual machine. Each frame has a set of local variables and an operand stack. Frames also contain a reference to a constant pool, but since all constant pools for all classes in a package are merged, the reference is to the constant pool for the current class' package.

javacard:jcvm:3.6_representation_of_objects

2017-05-13T04:10:34+00:00

3.6 Representation of Objects The Java Card virtual machine does not mandate a particular internal structure for objects or a particular layout of their contents. However, the core components in a CAP file are defined assuming a default structure for certain runtime structures (such as descriptions of classes), and a default layout for the contents of dynamically allocated objects. Information from the descriptor component of the

javacard:jcvm:3.7_special_initialization_methods

2017-05-13T04:10:35+00:00

3.7 Special Initialization Methods The Java Card virtual machine supports instance initialization methods exactly as does the Java virtual machine. The Java Card virtual machine includes only limited support for class or interface initialization methods

javacard:jcvm:3.8_exceptions

2017-05-13T04:10:35+00:00

3.8 Exceptions Exception support in the Java Card virtual machine is identical to support for exceptions in the Java virtual machine.

javacard:jcvm:3.9_binary_file_formats

2017-05-13T04:10:36+00:00

3.9 Binary File Formats This specification defines two binary file formats which enable platform-independent development, distribution and execution of Java Card programs. The CAP file format describes files that contain executable code and can be downloaded and installed onto a Java Card technology-enabled device. A

javacard:jcvm:3.10.1_types_and_the_java_card_virtual_machine

2017-05-13T04:10:28+00:00

3.10.1 Types and the Java Card Virtual Machine The Java Card virtual machine supports only a subset of the types supported by the Java virtual machine. This subset is described in Chapter 2. Type support is reflected in the instruction set, as instructions encode the data types on which they operate.

javacard:jcvm:3.10_instruction_set_summary

2017-05-13T04:10:29+00:00

3.10 Instruction Set Summary The Java Card virtual machine instruction set is quite similar to the Java virtual machine instruction set. Individual instructions consist of a one-byte opcode and zero or more operands. The pseudo-code for the Java Card virtual machine's instruction fetch-decode-execute loop is the same. Multi-byte operand data is also encoded in

javacard:jcvm:3._structure_of_the_java_card_virtual_machine

2017-05-13T04:10:37+00:00

3. Structure of the Java Card Virtual Machine The specification of the Java Card virtual machine is in many ways quite similar to that of the Java virtual machine. This similarity is of course intentional, as the design of the Java Card virtual machine was based on that of the Java virtual machine. Rather than reiterate all the details of this specification which are shared with that of the Java virtual machine, this chapter will mainly refer to its counterpart in The Java Virtual Machine Speci…

javacard:jcvm:4.1.1_export_file_format

2017-05-13T04:10:38+00:00

4.1.1 Export File Format Export files are not used directly on a device that implements a Java Card virtual machine. However, the information in an export file is critical to the operation of the virtual machine on a device. An export file can be produced by a Java Card converter when a package is converted. This package's export file can be used later to convert another package that imports classes from the first package. Information in the export file is included in the CAP file of the second…

javacard:jcvm:4.1.2_cap_file_format

2017-05-13T04:10:38+00:00

4.1.2 CAP File Format A Java Card CAP file contains a binary representation of a package of classes that can be installed on a device and used to execute the package's classes on a Java Card virtual machine. A CAP file is produced by a Java Card converter when a package of classes is converted. A CAP file consists of a set of components, each of which describes a different aspect of the contents. The set of components in a CAP file can vary, depending on whether the file contains a library or…

javacard:jcvm:4.1.3_jar_file_container

2017-05-13T04:10:39+00:00

4.1.3 JAR File Container The JAR file format is used as the container format for CAP files. What this specification calls a “CAP file” is just a JAR file that contains the required set of CAP components (see Chapter 6, “The CAP File Format”). CAP file components are stored as files in a JAR file. Each CAP file component is located in a subdirectory called javacard that is in a directory representing the package. For example, the CAP file components of the package com.sun.framework are locate…

javacard:jcvm:4.1_java_card_platform_file_formats

2017-05-13T04:10:40+00:00

4.1 Java Card Platform File Formats Java programs are represented in compiled, binary form as class files. Java class files are used not only to execute programs on a Java virtual machine, but also to provide type and name information to a Java compiler. In the latter role, a class file is essentially used to document the

javacard:jcvm:4.2.1_the_aid_format

2017-05-13T04:10:01+00:00

4.2.1 The AID Format This section presents a minimal description of the AID data format used in Java Card technology. For complete details, refer to ISO 7816-5, AID Registration Category `D' format. The AID format used by the Java Card platform is an array of bytes that can be interpreted as two distinct pieces, as shown in

javacard:jcvm:4.2.2_aid_usage

2017-05-13T04:11:07+00:00

4.2.2 AID Usage In the Java platform, packages are uniquely identified using Unicode strings and a naming scheme based on internet domain names. In the Java Card platform, packages and applets are identified using AIDs. Any package that is represented in an export file must be assigned a unique AID. The AID for a package is constructed from the concatenation of the company's RID and a PIX for that package. This AID corresponds to the string name for the package, as shown in

javacard:jcvm:4.2_aid-based_naming

2017-05-13T04:11:08+00:00

4.2 AID-based Naming This section describes the mechanism used for naming applets and packages in Java Card CAP files and export files, and custom components in Java Card CAP files. Java class files use Unicode strings to name Java packages. As the Java Card platform does not include support for strings, an alternative mechanism for naming is provided.

javacard:jcvm:4.3.1_externally_visible_items

2017-05-13T04:11:09+00:00

4.3.1 Externally Visible Items Classes (including Interfaces) in Java packages may be declared with public or package visibility. A class's methods and fields may be declared with public, protected, package or private visibility. For purposes of this document, we define public classes, public or protected fields, and public or protected methods to be externally visible from the package.

javacard:jcvm:4.3.2_private_tokens

2017-05-13T04:11:10+00:00

4.3.2 Private Tokens Items that are not externally visible are internally visible. Internally visible items are not described in a package's export file, but some such items use private tokens to represent internal references. External references are represented by public tokens. There are three kinds of items that can be assigned private tokens.

javacard:jcvm:4.3.3_the_export_file_and_conversion

2017-05-13T04:11:11+00:00

4.3.3 The Export File and Conversion An export file contains entries for externally visible items in the package. Each entry holds the item's name and its token. Some entries may include additional information as well. For detailed information on the export file format, see

javacard:jcvm:4.3.4_references_-_external_and_internal

2017-05-13T04:11:13+00:00

4.3.4 References - External and Internal In the context of a CAP file, references to items are made indirectly through a package's constant pool. References to items in other packages are called external, and are represented in terms of tokens. References to items in the same CAP file are called internal, and are represented either in terms of tokens, or in a different internal format.

javacard:jcvm:4.3.5_installation_and_linking

2017-05-13T04:11:13+00:00

4.3.5 Installation and Linking External references in a CAP file can be resolved on a device from token form into the internal representation used by the virtual machine. A token can only be resolved in the context of the package that defines it. Just as the export file maps from a package's externally visible names to tokens, there is a set of link information for each package on the device that maps from tokens to resolved references.

javacard:jcvm:4.3.6_token_assignment

2017-05-13T04:11:14+00:00

4.3.6 Token Assignment Tokens for an API are assigned by the API's owner and published in the package export file(s) for that API. Since the name-to-token mappings are published, an API owner may choose any order for tokens (subject to the constraints listed below).

javacard:jcvm:4.3.7.1_package

2017-05-13T04:11:14+00:00

4.3.7.1 Package All package references from within a CAP file are assigned private package tokens. Package token values must be in the range from 0 to 127, inclusive. The tokens for all the packages referenced from classes in a CAP file are numbered consecutively starting at zero. The ordering of package tokens is not specified.

javacard:jcvm:4.3.7.2_classes_and_interfaces

2017-05-13T04:11:16+00:00

4.3.7.2 Classes and Interfaces All externally visible classes and interfaces in a package are assigned public class tokens. Class token values must be in the range from 0 to 254, inclusive. The tokens for all the public classes and interfaces in a package are numbered consecutively starting at zero. The ordering of class tokens is not specified.

javacard:jcvm:4.3.7.3_static_fields

2017-05-13T04:11:16+00:00

4.3.7.3 Static Fields All externally visible static fields in a package are assigned public static field tokens. The tokens for all externally visible static fields in a class are numbered consecutively starting at zero. Static fields token values must be in the range from 0 to 255, inclusive. The ordering of static field tokens is not specified.

javacard:jcvm:4.3.7.4_static_methods_and_constructors

2017-05-13T04:11:18+00:00

4.3.7.4 Static Methods and Constructors All externally visible static methods and constructors in a package are assigned public static method tokens. Constructors are included in this category because they are statically bound. Static method token values must be in the range from 0 to 255, inclusive. The tokens for all the externally visible static methods and constructors in a class are numbered consecutively starting at zero. The ordering of static method tokens is not specified.

javacard:jcvm:4.3.7.5_instance_fields

2017-05-13T04:11:18+00:00

4.3.7.5 Instance Fields All instance fields defined in a package are assigned either public or private instance field tokens. The scope of a set of instance field tokens is limited to the class that declares the instance fields, not including the fields declared by superclasses of that class.

javacard:jcvm:4.3.7.6_virtual_methods

2017-05-13T04:11:19+00:00

4.3.7.6 Virtual Methods Virtual methods are instance methods that are resolved dynamically. The set includes all public, protected and package-visible instance methods. Private instance methods and all constructors are not virtual methods, but instead are resolved statically during compilation.

javacard:jcvm:4.3.7.7_interface_methods

2017-05-13T04:11:20+00:00

4.3.7.7 Interface Methods All interface methods defined in a package are assigned public interface method tokens, as interface methods are always public. Interface methods tokens values must be in the range from 0 to 127, inclusive. The tokens for all the interface methods defined in or inherited by an interface are numbered consecutively starting at zero. The token value for an interface method in a given interface is unrelated to the token values of that same method in any of the interface's …

javacard:jcvm:4.3.7_token_details

2017-05-13T04:11:21+00:00

4.3.7 Token Details Each kind of item in a package has its own independent scope for tokens of that kind. The token range and assignment rules for each kind are listed in TABLE 4-2. Token Type Range Type Scope Package 0 - 127 Private Package

javacard:jcvm:4.3_token-based_linking

2017-05-13T04:11:22+00:00

4.3 Token-based Linking This section describes a scheme that allows downloaded software to be linked against APIs on a Java Card technology enabled device. The scheme represents referenced items as opaque tokens, instead of Unicode strings as are used in Java class files. The two basic requirements of this linking scheme are that it allows linking on the device, and that it does not require internal implementation details of APIs to be revealed to clients of those APIs. Secondary requirements a…

javacard:jcvm:4.4_binary_compatibility

2017-05-13T04:11:22+00:00

4.4 Binary Compatibility In the Java programming language the granularity of binary compatibility can be between classes since binaries are stored in individual class files. In Java Card systems Java packages are processed as a single unit, and therefore the granularity of binary compatibility is between packages. In Java Card systems the binary of a package is represented in a CAP file, and the

javacard:jcvm:4.5.1_assigning

2017-05-13T04:10:01+00:00

4.5.1 Assigning The major and minor versions of a package are assigned by the package provider. It is recommended that the initial implementation of a package be assigned a major version of 1 and a minor version of 0. However, any values may be chosen. It is also recommended that when either a major or a minor version is incremented, it is incremented exactly by 1.

javacard:jcvm:4.5.2_linking

2017-05-13T04:09:13+00:00

4.5.2 Linking Both an export file and a CAP file contain the major and minor version numbers of the package described. When a CAP file is installed on a Java Card technology-enabled device a resident image of the package is created, and the major and minor version numbers are recorded as part of that image. When an export file is used during preparation of a CAP file, the version numbers indicated in the export file are recorded in the CAP file.

javacard:jcvm:4.5_package_versions

2017-05-13T04:09:13+00:00

4.5 Package Versions Each implementation of a package in a Java Card system is assigned a pair of major and minor version numbers. These version numbers are used to indicate binary compatibility or incompatibility between successive implementations of a package.

javacard:jcvm:4._binary_representation

2017-05-13T04:09:14+00:00

4. Binary Representation This chapter presents information about the binary representation of Java Card programs. Java Card technology-based binaries (“Java Card binaries”) are usually contained in files, therefore this chapter addresses binary representation in terms of this common case.

javacard:jcvm:5.1_export_file_name

2017-05-13T04:09:16+00:00

5.1 Export File Name As described in Section 4.1.1, Export File Format, the name of a export file must be the last portion of the package specification followed by the extension `.exp'. For example, the name of the export file of the javacard.framework package must be framework.exp

javacard:jcvm:5.2_containment_in_a_jar_file

2017-05-13T04:09:17+00:00

5.2 Containment in a JAR File As described in Section 4.1.3, JAR File Container, Java Card CAP files are contained in a JAR file. If an export file is also stored in a JAR file, it must also be located in a directory called javacard that is a subdirectory of the package's directory. For example, the

javacard:jcvm:5.3_ownership

2017-05-13T04:09:17+00:00

5.3 Ownership An export file is owned by the entity that owns the package it represents. The owner of a package defines the API of that package, and may or may not provide all implementations of that package. All implementations, however, must conform to the definition provided in the

javacard:jcvm:5.4_hierarchies_represented

2017-05-13T04:09:19+00:00

5.4 Hierarchies Represented Classes and interfaces represented in an export file include public elements defined within their respective hierarchies. For example, instead of indicating the immediate superclass or superinterface, all public superclasses or superinterfaces are listed. This design concept is applied not only to superclasses or superinterfaces, but also to virtual methods and implemented interfaces.

javacard:jcvm:5.5_export_file

2017-05-13T04:09:19+00:00

5.5 Export File An export file is defined by the following structure: The items in the ExportFile structure are as follows: magic The magic item contains the magic number identifying the ExportFile format; it has the value 0x00FACADE. minor_version, major_version

javacard:jcvm:5.6.1_constant_package

2017-05-13T04:09:20+00:00

5.6.1 CONSTANT_Package The CONSTANT_Package_info structure is used to represent a package: The items of the CONSTANT_Package_info structure are the following: tag The tag item has the value of CONSTANT_Package (13). flags The flags item is a mask of modifiers that apply to this package. The

javacard:jcvm:5.6.2_constant_classref

2017-05-13T04:09:21+00:00

5.6.2 CONSTANT_Classref The CONSTANT_Classref_info structure is used to represent a class or interface: The items of the CONSTANT_Classref_info structure are the following: tag The tag item has the value of CONSTANT_Classref (7). name_index

javacard:jcvm:5.6.3_constant_integer

2017-05-13T04:09:22+00:00

5.6.3 CONSTANT_Integer The CONSTANT_Integer_info structure is used to represent four-byte numeric (int) constants: The items of the CONSTANT_Integer_info structure are the following: tag The tag item has the value of CONSTANT_Integer (3). bytes

javacard:jcvm:5.6.4_constant_utf8

2017-05-13T04:09:22+00:00

5.6.4 CONSTANT_Utf8 The CONSTANT_Utf8_info structure is used to represent constant string values. UTF-8 strings are encoded in the same way as described in The Java Virtual Machine Specification (§ 4.4.7). The CONSTANT_Utf8_info structure is:

javacard:jcvm:5.6_constant_pool

2017-05-13T04:09:23+00:00

5.6 Constant Pool All constant_pool table entries have the following general format: Each item in the constant_pool must begin with a 1-byte tag indicating the kind of cp_info entry. The content of the info array varies with the value of tag. The valid tags and their values are listed in

javacard:jcvm:5.7_classes_and_interfaces

2017-05-13T04:09:24+00:00

5.7 Classes and Interfaces Each class and interface is described by a variable-length class_info structure. The format of this structure is: The items of the class_info structure are as follows: token The value of the token item is the class token (

javacard:jcvm:5.8_fields

2017-05-13T04:09:26+00:00

5.8 Fields Each field is described by a variable-length field_info structure. The format of this structure is: The items of the field_info structure are as follows: token The token item is the token assigned to this field. There are three scopes for field tokens:

javacard:jcvm:5.9_methods

2017-05-13T04:09:26+00:00

5.9 Methods Each method is described by a variable-length method_info structure. The format of this structure is: The items of the method_info structure are as follows: token The token item is the token assigned to this method. If this method is a

javacard:jcvm:5.10.1_constantvalue_attribute

2017-05-13T04:09:14+00:00

5.10.1 ConstantValue Attribute The ConstantValue attribute is a fixed-length attribute used in the attributes table of the field_info structures. A ConstantValue attribute represents the value of a final static field (compile-time constant); that is, both the

javacard:jcvm:5.10_attributes

2017-05-13T04:09:16+00:00

5.10 Attributes Attributes are used in the field_info ( Section 5.8, Fields) structure of the export file format. All attributes have the following general format:

javacard:jcvm:5._the_export_file_format

2017-05-13T04:09:27+00:00

5. The Export File Format This chapter describes the export file format. Compliant Java Card Converters must be capable of producing and consuming all export files that conform to the specification provided in this chapter. An export file consists of a stream of 8-bit bytes. All 16-bit and 32-bit quantities are constructed by reading in two and four consecutive 8-bit bytes, respectively. Multibyte data items are always stored in big-endian order, where the high-order bytes come first.

javacard:jcvm:6.1.1_containment_in_a_jar_file

2017-05-13T04:09:28+00:00

6.1.1 Containment in a JAR File Each CAP file component is represented as a single file. The component file names are enumerated in TABLE 6-2. These names are not case sensitive. Component Type File Name COMPONENT_Header Header.cap COMPONENT_Directory

javacard:jcvm:6.1.2_defining_new_components

2017-05-13T04:09:29+00:00

6.1.2 Defining New Components Java Card CAP files are permitted to contain new, or custom, components. All new components not defined as part of this specification must not affect the semantics of the specified components, and Java Card virtual machines must be able to accept CAP files that do not contain new components. Java Card virtual machine implementations are required to silently ignore components they do not recognize.

javacard:jcvm:6.1_component_model

2017-05-13T04:10:11+00:00

6.1 Component Model A Java Card CAP file consists of a set of components. Each component describes a set of elements in the Java package defined, or an aspect of the CAP file. A complete CAP file must contain all of the required components specified in this chapter. Three

javacard:jcvm:6.2_installation

2017-05-13T04:10:12+00:00

6.2 Installation Installing a CAP file components onto a Java Card technology-enabled device entails communication between a Java Card technology-enabled terminal and that device. While it is beyond the scope of this specification to define a load file format or installation protocol between a terminal and a device, the CAP file component order shown in

javacard:jcvm:6.3_header_component

2017-05-13T04:10:12+00:00

6.3 Header Component The Header Component contains general information about this CAP file and the package it defines. It is described by the following variable-length structure: The items in the header_component structure are as follows: tag The

javacard:jcvm:6.4_directory_component

2017-05-13T04:10:14+00:00

6.4 Directory Component The Directory Component lists the size of each of the components defined in this CAP file. When an optional component is not included, such as the Applet Component ( Section 6.5, Applet Component), Export Component ( Section 6.12, Export Component), or Debug Component ( Section 6.14, Debug Component), it is represented in the Directory Component with size equal to zero. The Directory Component also includes entries for new (or custom) components.

javacard:jcvm:6.5_applet_component

2017-05-13T04:10:14+00:00

6.5 Applet Component The Applet Component contains an entry for each of the applets defined in this package. Applets are defined by implementing a non-abstract subclass, direct or indirect, of the javacard.framework.Applet class.^[2] If no applets are defined, this component must not be present in this CAP file.

javacard:jcvm:6.6_import_component

2017-05-13T04:10:15+00:00

6.6 Import Component The Import Component lists the set of packages imported by the classes in this package. It does not include an entry for the package defined in this CAP file. The Import Component is represented by the following structure: The items in the

javacard:jcvm:6.7.1_constant_classref

2017-05-13T04:10:15+00:00

6.7.1 CONSTANT_Classref The CONSTANT_Classref_info structure is used to represent a reference to a class or an interface. The class or interface may be defined in this package or in an imported package. The items in the CONSTANT_Classref_info structure are the following:

javacard:jcvm:6.7.2_constant_instancefieldref_constant_virtualmethodref_and_constant_supermethodref

2017-05-13T04:10:17+00:00

6.7.2 CONSTANT_InstanceFieldref, CONSTANT_VirtualMethodref, and CONSTANT_SuperMethodref References to instance fields, and virtual methods are represented by similar structures: The items in these structures are as follows: tag The tag item of a

javacard:jcvm:6.7.3_constant_staticfieldref_and_constant_staticmethodref

2017-05-13T04:10:17+00:00

6.7.3 CONSTANT_StaticFieldref and CONSTANT_StaticMethodref References to static fields and methods are represented by similar structures: The items in these structures are as follows: tag The tag item of a CONSTANT_StaticFieldref_info structure has the value

javacard:jcvm:6.7_constant_pool_component

2017-05-13T04:10:18+00:00

6.7 Constant Pool Component The Constant Pool Component contains an entry for each of the classes, methods, and fields referenced by elements in the Method Component ( Section 6.9, Method Component) of this CAP file. The referencing elements in the Method Component may be instructions in the methods or exception handler catch types in the exception handler table.

javacard:jcvm:6.8.1_type_descriptor

2017-05-13T04:10:19+00:00

6.8.1 type_descriptor The type_descriptor structure represents the type of a field or the signature of a method. The type_descriptor structure contains the following elements: nibble_count The nibble_count value represents the number of nibbles required to describe the type encoded in the type array.

javacard:jcvm:6.8.2.1_interface_info_and_class_info_shared_items

2017-05-13T04:10:20+00:00

6.8.2.1 interface_info and class_info shared Items flags The flags item is a mask of modifiers used to describe this interface or class. Valid values are shown in the following table: Name Value ACC_INTERFACE 0x8 ACC_SHAREABLE 0x4 ACC_REMOTE

javacard:jcvm:6.8.2.2_interface_info_items

2017-05-13T04:10:03+00:00

6.8.2.2 interface_info Items superinterfaces[] The superinterfaces[] item of the interface_info structure is an array of class_ref structures representing the superinterfaces of this interface. The class_ref structure is defined as part of the CONSTANT_Classref_info

javacard:jcvm:6.8.2.3_class_info_items

2017-05-13T04:11:57+00:00

6.8.2.3 class_info Items super_class_ref The super_class_ref item of the class_info structure is a class_ref structure representing the superclass of this class. The class_ref structure is defined as part of the CONSTANT_Classref_info structure ( Section 6.7.1, CONSTANT_Classref).

javacard:jcvm:6.8.2.4_implemented_interface_info

2017-05-13T04:11:58+00:00

6.8.2.4 implemented_interface_info The implemented_interface_info structure is defined as follows: The items in the implemented_interface_info structure are defined as follows: interface The interface item has the form of a class_ref structure. The

javacard:jcvm:6.8.2.5_remote_interface_info

2017-05-13T04:11:59+00:00

6.8.2.5 remote_interface_info If the value of the ACC_REMOTE flag is zero, this structure is defined as: remote_interface_info { } If the value of the ACC_REMOTE flag is one, this structure is defined as: The remote_interface_info structure is defined as:

javacard:jcvm:6.8.2_interface_info_and_class_info

2017-05-13T04:12:00+00:00

6.8.2 interface_info and class_info The interface_info and class_info structures represent interfaces and classes, respectively. The two are differentiated by the value of the high bit in the structures. They are defined as follows:

javacard:jcvm:6.8_class_component

2017-05-13T04:12:00+00:00

6.8 Class Component The Class Component describes each of the classes and interfaces defined in this package. It does not contain complete access information and content details for each class and interface. Instead, the information included is limited to that required to execute operations associated with a particular class or interface, without performing verification. Complete details regarding the classes and interfaces defined in this package are included in the Descriptor Component (

javacard:jcvm:6.9.1_exception_handler_info

2017-05-13T04:12:02+00:00

6.9.1 exception_handler_info The exception_handler_info structure is defined as follows: The items in the exception_handler_info structure are as follows: start_offset, active_length The start_offset and active_length pair indicate the active range (try block) an exception handler. The

javacard:jcvm:6.9.2_method_info

2017-05-13T04:12:02+00:00

6.9.2 method_info The method_info structure is defined as follows: The items in the method_info structure are as follows: method_header The method_header item represents either a method_header_info or an extended_method_header_info structure:

javacard:jcvm:6.9_method_component

2017-05-13T04:12:04+00:00

6.9 Method Component The Method Component describes each of the methods declared in this package, excluding methods and interface method declarations. Abstract methods defined by classes (not interfaces) are included. The exception handlers associated with each method are also described.

javacard:jcvm:6.10_static_field_component

2017-05-13T04:09:29+00:00

6.10 Static Field Component The Static Field Component contains all of the information required to create and initialize an image of all of the static fields defined in this package, referred to as the static field image. Offsets to particular static fields are offsets into the static field image, not the Static Field Component.

javacard:jcvm:6.11_reference_location_component

2017-05-13T04:09:30+00:00

6.11 Reference Location Component The Reference Location Component represents lists of offsets into the info item of the Method Component ( Section 6.9, Method Component) to items that contain indices into the constant_pool[] array of the Constant Pool Component ( Section 6.7, Constant Pool Component). This includes all constant pool index operands of instructions, and all non-zero

javacard:jcvm:6.12_export_component

2017-05-13T04:09:31+00:00

6.12 Export Component The Export Component lists all static elements in this package that may be imported by classes in other packages. Instance fields and virtual methods are not represented in the Export Component. If this CAP file does not include an Applet Component (

javacard:jcvm:6.13.1_class_descriptor_info

2017-05-13T04:09:32+00:00

6.13.1 class_descriptor_info The class_descriptor_info structure is used to describe a class or interface defined in this package: The items of the class_descriptor_info structure are as follows: token The token item represents the class token (

javacard:jcvm:6.13.2_field_descriptor_info

2017-05-13T04:09:32+00:00

6.13.2 field_descriptor_info The field_descriptor_info structure is used to describe a field defined in this package: The items of the field_descriptor_info structure are as follows: token The token item represents the token of this field. If this field is private or package-visible static field it does not have a

javacard:jcvm:6.13.3_method_descriptor_info

2017-05-13T04:09:33+00:00

6.13.3 method_descriptor_info The method_descriptor_info structure is used to describe a method defined in this package. This structure contains sufficient information to locate and parse the methods in the Method Component, while the Method Component does not.

javacard:jcvm:6.13.4_type_descriptor_info

2017-05-13T04:10:03+00:00

6.13.4 type_descriptor_info The type_descriptor_info structure represents the types of fields and signatures of methods defined in this package: The type_descriptor_info structure contains the following elements: constant_pool_count The constant_pool

javacard:jcvm:6.13_descriptor_component

2017-05-13T04:10:07+00:00

6.13 Descriptor Component The Descriptor Component provides sufficient information to parse and verify all elements of the CAP file. It references, and therefore describes, elements in the Constant Pool Component ( Section 6.7, Constant Pool Component), Class Component ( Section 6.8, Class Component), Method Component (

javacard:jcvm:6.14.1.1_the_field_debug_info_structure

2017-05-13T04:10:08+00:00

6.14.1.1 The field_debug_info Structure The field_debug_info structure describes a field in a class. It can describe either an instance field, a static field, or a constant (primitive final static) field. The contents union will have the form of a token_var

javacard:jcvm:6.14.1.2_the_method_debug_info_structure

2017-05-13T04:10:09+00:00

6.14.1.2 The method_debug_info Structure The method_debug_info structure describes a method of a class. It can describe methods that are either virtual or non-virtual (static or initialization methods). The structure is defined as follows: The items in the

javacard:jcvm:6.14.1_the_class_debug_info_structure

2017-05-13T04:10:09+00:00

6.14.1 The class_debug_info Structure The class_debug_info structure contains all of the debugging information for a class or interface. It also contains tables of debugging information for all its classes' fields and methods. The items in the class_debug_info

javacard:jcvm:6.14_debug_component

2017-05-13T04:10:10+00:00

6.14 Debug Component This section specifies the format for the Debug Component. The Debug Component contains all the metadata necessary for debugging a package on a suitably instrumented Java Card virtual machine. It is not required for executing Java Card programs in a non-debug environment.

javacard:jcvm:6._the_cap_file_format

2017-05-13T04:12:04+00:00

6. The CAP File Format This chapter describes the Java Card converted applet (CAP) file format. Each CAP file contains all of the classes and interfaces defined in one Java package. Java Card Converters must be capable of producing CAP files that conform to the specification provided in this chapter.

javacard:jcvm:7.1_assumptions_the_meaning_of_must

2017-05-13T04:12:06+00:00

7.1 Assumptions: The Meaning of "Must" The description of each instruction is always given in the context of Java Card virtual machine code that satisfies the static and structural constraints of Chapter 6, “The CAP File Format”. In the description of individual Java Card virtual machine instructions, we frequently state that some situation

javacard:jcvm:7.2_reserved_opcodes

2017-05-13T04:12:06+00:00

7.2 Reserved Opcodes In addition to the opcodes of the instructions specified later this chapter, which are used in Java Card CAP files (see Chapter 6, “The CAP File Format”), two opcodes are reserved for internal use by a Java Card virtual machine implementation. If Sun Microsystems, Inc. extends the instruction set of the Java Card virtual machine in the future, these reserved opcodes are guaranteed not to be used.

javacard:jcvm:7.3_virtual_machine_errors

2017-05-13T04:12:07+00:00

7.3 Virtual Machine Errors A Java Card virtual machine may encounter internal errors or resource limitations that prevent it from executing correctly written Java programs. While The Java Virtual Machine Specification allows reporting and handling of virtual machine errors, it also states that they cannot ordinarily be handled by application code. This Virtual Machine Specification for the Java Card Platform, v2.2.2 is more restrictive in that it does not allow for any reporting or handling of …

javacard:jcvm:7.4_security_exceptions

2017-05-13T04:12:08+00:00

7.4 Security Exceptions Instructions of the Java Card virtual machine throw an instance of the class SecurityException when a security violation has been detected. The Java Card virtual machine does not mandate the complete set of security violations that can or will result in an exception being thrown. However, there is a minimum set that must be supported.

javacard:jcvm:7.5.1_aaload

2017-05-13T04:09:05+00:00

7.5.1 aaload Load reference from array Format aaload Forms aaload = 36 (0x24) Stack ..., arrayref, index -> ..., value Description The arrayref must be of type reference and must refer to an array whose components are of type reference. The index must be of type short. Both arrayref and index are popped from the operand stack. The reference value in the component of the array at index is retrieved and pushed onto the top of the operand stack.

javacard:jcvm:7.5.2_aastore

2017-05-13T04:11:24+00:00

7.5.2 aastore Store into reference array Format aastore Forms aastore = 55 (0x37) Stack ..., arrayref, index, value -> ... Description The arrayref must be of type reference and must refer to an array whose components are of type reference. The index must be of type short and the value must be of type reference. The arrayref, index and value are popped from the operand stack. The reference value is stored as the component of the array at index.

javacard:jcvm:7.5.3_aconst_null

2017-05-13T04:11:33+00:00

7.5.3 aconst_null Push null Format aconst_null Forms aconst_null = 1 (0x1) Stack ... -> ..., null Description Push the null object reference onto the operand stack.

javacard:jcvm:7.5.4_aload

2017-05-13T04:09:34+00:00

7.5.4 aload Load reference from local variable Format aload index Forms aload = 21 (0x15) Stack ... -> ..., objectref Description The index is an unsigned byte that must be a valid index into the local variables of the current frame (

javacard:jcvm:7.5.5_aload_n

2017-05-13T04:09:43+00:00

7.5.5 aload_ Load reference from local variable Format aload_ Forms aload_0 = 24 (0x18) aload_1 = 25 (0x19) aload_2 = 26 (0x1a) aload_3 = 27 (0x1b) Stack ... -> ..., objectref Description The must be a valid index into the local variables of the current frame (

javacard:jcvm:7.5.6_anewarray

2017-05-13T04:09:52+00:00

7.5.6 anewarray Create new array of reference Format anewarray indexbyte1 indexbyte2 Forms anewarray = 145 (0x91) Stack ..., count -> ..., arrayref Description The count must be of type short. It is popped off the operand stack. The count represents the number of components of the array to be created. The unsigned indexbyte1 and indexbyte2 are used to construct an index into the constant pool of the current package (

javacard:jcvm:7.5.7_areturn

2017-05-13T04:10:41+00:00

7.5.7 areturn Return reference from method Format areturn Forms areturn = 119 (0x77) Stack ..., objectref -> [empty] Description The objectref must be of type reference. The objectref is popped from the operand stack of the current frame (

javacard:jcvm:7.5.8_arraylength

2017-05-13T04:10:50+00:00

7.5.8 arraylength Get length of array Format arraylength Forms arraylength = 146 (0x92) Stack ..., arrayref -> ..., length Description The arrayref must be of type reference and must refer to an array. It is popped from the operand stack. The length of the array it references is determined. That length is pushed onto the top of the operand stack as a short.

javacard:jcvm:7.5.9_astore

2017-05-13T04:11:00+00:00

7.5.9 astore Store reference into local variable Format astore index Forms astore = 40 (0x28) Stack ..., objectref -> ... Description The index is an unsigned byte that must be a valid index into the local variables of the current frame (

javacard:jcvm:7.5.10_astore_n

2017-05-13T04:08:57+00:00

7.5.10 astore_ Store reference into local variable Format astore_ Forms astore_0 = 43 (0x2b) astore_1 = 44 (0x2c) astore_2 = 45 (0x2d) astore_3 = 46 (0x2e) Stack ..., objectref -> ... Description The must be a valid index into the local variables of the current frame (

javacard:jcvm:7.5.11_athrow

2017-05-13T04:08:57+00:00

7.5.11 athrow Throw exception or error Format athrow Forms athrow = 147 (0x93) Stack ..., objectref -> objectref Description The objectref must be of type reference and must refer to an object that is an instance of class Throwable or of a subclass of Throwable. It is popped from the operand stack. The objectref is then thrown by searching the current frame (

javacard:jcvm:7.5.12_baload

2017-05-13T04:08:59+00:00

7.5.12 baload Load byte or boolean from array Format baload Forms baload = 37 (0x25) Stack ..., arrayref, index -> ..., value Description The arrayref must be of type reference and must refer to an array whose components are of type byte or of type boolean. The index must be of type short. Both arrayref and index are popped from the operand stack. The byte value in the component of the array at index is retrieved, sign-extended to a short value, and pushed onto the top of the op…

javacard:jcvm:7.5.13_bastore

2017-05-13T04:08:59+00:00

7.5.13 bastore Store into byte or boolean array Format bastore Forms bastore = 56 (0x38) Stack ..., arrayref, index, value -> ... Description The arrayref must be of type reference and must refer to an array whose components are of type byte or of type boolean. The index and value must both be of type short. The arrayref, index and value are popped from the operand stack. The short value is truncated to a byte and stored as the component of the array indexed by index.

javacard:jcvm:7.5.14_bipush

2017-05-13T04:09:00+00:00

7.5.14 bipush Push byte Format bipush byte Forms bipush = 18 (0x12) Stack ... -> ..., value.word1, value.word2 Description The immediate byte is sign-extended to an int, and the resulting value is pushed onto the operand stack. Note - If a virtual machine does not support the int data type, the bipush instruction will not be available.

javacard:jcvm:7.5.15_bspush

2017-05-13T04:09:01+00:00

7.5.15 bspush Push byte Format bspush byte Forms bspush = 16 (0x10) Stack ... -> ..., value Description The immediate byte is sign-extended to a short, and the resulting value is pushed onto the operand stack.

javacard:jcvm:7.5.16_checkcast

2017-05-13T04:09:02+00:00

7.5.16 checkcast Check whether object is of given type Format checkcast atype indexbyte1 indexbyte2 Forms checkcast = 148 (0x94) Stack ..., objectref -> ..., objectref Description The unsigned byte atype is a code that indicates if the type against which the object is being checked is an array type or a class type. It must take one of the following values or zero:

javacard:jcvm:7.5.17_dup

2017-05-13T04:09:02+00:00

7.5.17 dup Duplicate top operand stack word Format dup Forms dup = 61 (0x3d) Stack ..., word -> ..., word, word Description The top word on the operand stack is duplicated and pushed onto the operand stack. The dup instruction must not be used unless word contains a 16-bit data type.

javacard:jcvm:7.5.18_dup_x

2017-05-13T04:09:03+00:00

7.5.18 dup_x Duplicate top operand stack words and insert below Format dup_x mn Forms dup_x = 63 (0x3f) Stack ..., wordN, ..., wordM, ..., word1 -> ..., wordM, ..., word1, wordN, ..., wordM, ..., word1 Description The unsigned byte mn is used to construct two parameter values. The high nibble, (mn& 0xf0)

javacard:jcvm:7.5.19_dup2

2017-05-13T04:09:03+00:00

7.5.19 dup2 Duplicate top two operand stack words Format dup2 Forms dup2 = 62 (0x3e) Stack ..., word2, word1 -> ..., word2, word1, word2, word1 Description The top two words on the operand stack are duplicated and pushed onto the operand stack, in the original order.

javacard:jcvm:7.5.20_getfield_t

2017-05-13T04:09:05+00:00

7.5.20 getfield_ Fetch field from object Format getfield_ index Forms getfield_a = 131 (0x83) getfield_b = 132 (0x84) getfield_s = 133 (0x85) getfield_i = 134 (0x86) Stack ..., objectref -> ..., value OR ..., objectref -> ..., value.word1, value.word2

javacard:jcvm:7.5.21_getfield_t_this

2017-05-13T04:09:06+00:00

7.5.21 getfield__this Fetch field from current object Format getfieldthis index Forms getfield_a_this = 173 (0xad) getfield_b_this = 174 (0xae) getfield_s_this = 175 (0xaf) getfield_i_this = 176 (0xb0) Stack ... -> ..., value OR

javacard:jcvm:7.5.22_getfield_t_w

2017-05-13T04:09:07+00:00

7.5.22 getfield__w Fetch field from object (wide index) Format getfieldw indexbyte1 indexbyte2 Forms getfield_a_w = 169 (0xa9) getfield_b_w = 170 (0xaa) getfield_s_w = 171 (0xab) getfield_i_w = 172 (0xac) Stack ..., objectref -> ...

javacard:jcvm:7.5.23_getstatic_t

2017-05-13T04:09:08+00:00

7.5.23 getstatic_ Get static field from class Format getstatic_ indexbyte1 indexbyte2 Forms getstatic_a = 123 (0x7b) getstatic_b = 124 (0x7c) getstatic_s = 125 (0x7d) getstatic_i = 126 (0x7e) Stack ... -> ..., value OR ... ->

javacard:jcvm:7.5.24_goto

2017-05-13T04:09:08+00:00

7.5.24 goto Branch always Format goto branch Forms goto = 112 (0x70) Stack No change Description The value branch is used as a signed 8-bit offset. Execution proceeds at that offset from the address of the opcode of this goto instruction. The target address must be that of an opcode of an instruction within the method that contains this goto instruction.

javacard:jcvm:7.5.25_goto_w

2017-05-13T04:09:10+00:00

7.5.25 goto_w Branch always (wide index) Format goto_w branchbyte1 branchbyte2 Forms goto_w = 168 (0xa8) Stack No change Description The unsigned bytes branchbyte1 and branchbyte2 are used to construct a signed 16-bit branchoffset, where branchoffset is (branchbyte1

javacard:jcvm:7.5.26_i2b

2017-05-13T04:09:10+00:00

7.5.26 i2b Convert int to byte Format i2b Forms i2b = 93 (0x5d) Stack ..., value.word1, value.word2 -> ..., result Description The value on top of the operand stack must be of type int. It is popped from the operand stack and converted to a byte result by taking the low-order 16 bits of the int value, and discarding the high-order 16 bits. The low-order word is truncated to a byte, then sign-extended to a short result. The result is pushed onto the operand stack.

javacard:jcvm:7.5.27_i2s

2017-05-13T04:09:11+00:00

7.5.27 i2s Convert int to short Format i2s Forms i2s = 94 (0x5e) Stack ..., value.word1, value.word2 -> ..., result Description The value on top of the operand stack must be of type int. It is popped from the operand stack and converted to a short result by taking the low-order 16 bits of the int value and discarding the high-order 16 bits. The result is pushed onto the operand stack.

javacard:jcvm:7.5.28_iadd

2017-05-13T04:09:11+00:00

7.5.28 iadd Add int Format iadd Forms iadd = 66 (0x42) Stack ..., value1.word1, value1.word2, value2.word1, value2.word2 -> ..., result.word1, result.word2 Description Both value1 and value2 must be of type int. The values are popped from the operand stack. The int result is value1 + value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.29_iaload

2017-05-13T04:10:05+00:00

7.5.29 iaload Load int from array Format iaload Forms iaload = 39 (0x27) Stack ..., arrayref, index -> ..., value.word1, value.word2 Description The arrayref must be of type reference and must refer to an array whose components are of type int. The index must be of type short. Both arrayref and index are popped from the operand stack. The int value in the component of the array at index is retrieved and pushed onto the top of the operand stack.

javacard:jcvm:7.5.30_iand

2017-05-13T04:11:24+00:00

7.5.30 iand Boolean AND int Format iand Forms iand = 84 (0x54) Stack ..., value1.word1, value1.word2, value2.word1, value2.word2 -> ..., result.word1, result.word2 Description Both value1 and value2 must be of type int. They are popped from the operand stack. An int result is calculated by taking the bitwise AND (conjunction) of value1 and value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.31_iastore

2017-05-13T04:11:25+00:00

7.5.31 iastore Store into int array Format iastore Forms iastore = 58 (0x3a) Stack ..., arrayref, index, value.word1, value.word2 -> ... Description The arrayref must be of type reference and must refer to an array whose components are of type int. The index must be of type short and value must be of type int. The arrayref, index and value are popped from the operand stack. The int value is stored as the component of the array indexed by index.

javacard:jcvm:7.5.32_icmp

2017-05-13T04:11:26+00:00

7.5.32 icmp Compare int Format icmp Forms icmp = 95 (0x5f) Stack ..., value1.word1, value1.word2, value2.word1, value2.word2 -> ..., result Description Both value1 and value2 must be of type int. They are both popped from the operand stack, and a signed integer comparison is performed. If value1 is greater than value2, the short value 1 is pushed onto the operand stack. If value1 is equal to value2, the short value 0 is pushed onto the operand stack. If value1 is less than value…

javacard:jcvm:7.5.33_iconst_i

2017-05-13T04:11:28+00:00

7.5.33 iconst_ Push int constant Format iconst_ Forms iconst_m1 = 10 (0x09) iconst_0 = 11 (0xa) iconst_1 = 12 (0xb) iconst_2 = 13 (0xc) iconst_3 = 14 (0xd) iconst_4 = 15 (0xe) iconst_5 = 16 (0xf) Stack ... -> ..., .word1, .word2 Description

javacard:jcvm:7.5.34_idiv

2017-05-13T04:11:28+00:00
7.5.34 idiv Divide int Format idiv Forms idiv = 72 (0x48) Stack ..., value1.word1, value1.word2, value2.word1, value2.word2 -> ..., result.word1, result.word2 Description Both value1 and value2 must be of type int. The values are popped from the operand stack. The int result is the value of the Java expression value1 / value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.35_if_acmp_cond

2017-05-13T04:11:29+00:00
7.5.35 if_acmp Branch if reference comparison succeeds. Format if_acmp branch Forms if_acmpeq = 104 (0x68) if_acmpne = 105 (0x69) Stack ..., value1, value2 -> ... Description Both value1 and value2 must be of type reference. They are both popped from the operand stack and compared. The results of the comparisons are as follows:

javacard:jcvm:7.5.36_if_acmp_cond_w

2017-05-13T04:11:29+00:00
7.5.36 if_acmp_w Branch if reference comparison succeeds (wide index) Format if_acmp_w branchbyte1 branchbyte2 Forms if_acmpeq_w = 160 (0xa0) if_acmpne_w = 161 (0xa1) Stack ..., value1, value2 -> ... Description Both value1 and value2 must be of type reference. They are both popped from the operand stack and compared. The results of the comparisons are as follows:

javacard:jcvm:7.5.37_if_scmp_cond

2017-05-13T04:11:31+00:00
7.5.37 if_scmp Branch if short comparison succeeds Format if_scmp branch Forms if_scmpeq = 106 (0x6a) if_scmpne = 107 (0x6b) if_scmplt = 108 (0x6c) if_scmpge = 109 (0x6d) if_scmpgt = 110 (0x6e) if_scmple = 111 (0x6f) Stack ..., value1, value2

javacard:jcvm:7.5.38_if_scmp_cond_w

2017-05-13T04:11:31+00:00
7.5.38 if_scmp_w Branch if short comparison succeeds (wide index) Format if_scmp_w branchbyte1 branchbyte2 Forms if_scmpeq_w = 162 (0xa2) if_scmpne_w = 163 (0xa3) if_scmplt_w = 164 (0xa4) if_scmpge_w = 165 (0xa5) if_scmpgt_w = 166 (0xa6) if_scmple_w = 167 (0xa7)

javacard:jcvm:7.5.39_if_cond

2017-05-13T04:11:33+00:00
7.5.39 if Branch if short comparison with zero succeeds Format if branch Forms ifeq = 96 (0x60) ifne = 97 (0x61) iflt = 98 (0x62) ifge = 99 (0x63) ifgt = 100 (0x64) ifle = 101 (0x65) Stack ..., value -> ... Description The value must be of type short. It is popped from the operand stack and compared against zero. All comparisons are signed. The results of the comparisons are as follows:

javacard:jcvm:7.5.40_if_cond_w

2017-05-13T04:11:35+00:00
7.5.40 if_w Branch if short comparison with zero succeeds (wide index) Format if_w branchbyte1 branchbyte2 Forms ifeq_w = 152 (0x98) ifne_w = 153 (0x99) iflt_w = 154 (0x9a) ifge_w = 155 (0x9b) ifgt_w = 156 (0x9c) ifle_w = 157 (0x9d)

javacard:jcvm:7.5.41_ifnonnull

2017-05-13T04:11:35+00:00
7.5.41 ifnonnull Branch if reference not null Format ifnonnull branch Forms ifnonnull = 103 (0x67) Stack ..., value -> ... Description The value must be of type reference. It is popped from the operand stack. If the value is not null, branch is used as signed 8-bit offset, and execution proceeds at that offset from the address of the opcode of this ifnonnull instruction. The target address must be that of an opcode of an instruction within the method that contains this ifnonnul…

javacard:jcvm:7.5.42_ifnonnull_w

2017-05-13T04:11:36+00:00
7.5.42 ifnonnull_w Branch if reference not null (wide index) Format ifnonnull_w branchbyte1 branchbyte2 Forms ifnonnull_w = 159 (0x9f) Stack ..., value -> ... Description The value must be of type reference. It is popped from the operand stack. If the value is not null, the unsigned bytes branchbyte1 and branchbyte2 are used to construct a signed 16-bit branchoffset, where branchoffset is (branchbyte1

javacard:jcvm:7.5.43_ifnull

2017-05-13T04:11:37+00:00
7.5.43 ifnull Branch if reference is null Format ifnull branch Forms ifnull = 102 (0x66) Stack ..., value -> ... Description The value must be of type reference. It is popped from the operand stack. If the value is null, branch is used as signed 8-bit offset, and execution proceeds at that offset from the address of the opcode of this ifnull instruction. The target address must be that of an opcode of an instruction within the method that contains this ifnull instruction.

javacard:jcvm:7.5.44_ifnull_w

2017-05-13T04:11:38+00:00
7.5.44 ifnull_w Branch if reference is null (wide index) Format ifnull_w branchbyte1 branchbyte2 Forms ifnull_w = 158 (0x9e) Stack ..., value -> ... Description The value must be of type reference. It is popped from the operand stack. If the value is null, the unsigned bytes branchbyte1 and branchbyte2 are used to construct a signed 16-bit branchoffset, where branchoffset is (branchbyte1

javacard:jcvm:7.5.45_iinc

2017-05-13T04:11:39+00:00
7.5.45 iinc Increment local int variable by constant Format iinc index const Forms iinc = 90 (0x5a) Stack No change Description The index is an unsigned byte. Both index and index + 1 must be valid indices into the local variables of the current frame (

javacard:jcvm:7.5.46_iinc_w

2017-05-13T04:11:40+00:00
7.5.46 iinc_w Increment local int variable by constant Format iinc_w index byte1 byte2 Forms iinc_w = 151 (0x97) Stack No change Description The index is an unsigned byte. Both index and index + 1 must be valid indices into the local variables of the current frame (

javacard:jcvm:7.5.47_iipush

2017-05-13T04:11:41+00:00
7.5.47 iipush Push int Format iipush byte1 byte2 byte3 byte4 Forms iipush = 20 (0x14) Stack ... -> ..., value1.word1, value1.word2 Description The immediate unsigned byte1, byte2, byte3, and byte4 values are assembled into a signed int where the value of the int is (byte1

javacard:jcvm:7.5.48_iload

2017-05-13T04:11:42+00:00
7.5.48 iload Load int from local variable Format iload index Forms iload = 23 (0x17) Stack ... -> ..., value1.word1, value1.word2 Description The index is an unsigned byte. Both index and index + 1 must be valid indices into the local variables of the current frame (

javacard:jcvm:7.5.49_iload_n

2017-05-13T04:10:06+00:00
7.5.49 iload_ Load int from local variable Format iload_ Forms iload_0 = 32 (0x20) iload_1 = 33 (0x21) iload_2 = 34 (0x22) iload_3 = 35 (0x23) Stack ... -> ..., value1.word1, value1.word2 Description Both and + 1 must be a valid indices into the local variables of the current frame (

javacard:jcvm:7.5.50_ilookupswitch

2017-05-13T04:09:35+00:00
7.5.50 ilookupswitch Access jump table by key match and jump Format ilookupswitch defaultbyte1 defaultbyte2 npairs1 npairs2 match-offset pairs... Pair Format matchbyte1 matchbyte2 matchbyte3 matchbyte4 offsetbyte1 offsetbyte2

javacard:jcvm:7.5.51_imul

2017-05-13T04:09:35+00:00
7.5.51 imul Multiply int Format imul Forms imul = 70 (0x46) Stack ..., value1.word1, value1.word2, value2.word1, value2.word2 -> ..., result.word1, result.word2 Description Both value1 and value2 must be of type int. The values are popped from the operand stack. The int result is value1 * value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.52_ineg

2017-05-13T04:09:36+00:00
7.5.52 ineg Negate int Format ineg Forms ineg = 76 (0x4c) Stack ..., value.word1, value.word2 -> ..., result.word1, result.word2 Description The value must be of type int. It is popped from the operand stack. The int result is the arithmetic negation of value, -value. The result is pushed onto the operand stack.

javacard:jcvm:7.5.53_instanceof

2017-05-13T04:09:37+00:00
7.5.53 instanceof Determine if object is of given type Format instanceof atype indexbyte1 indexbyte2 Forms instanceof = 149 (0x95) Stack ..., objectref -> ..., result Description The unsigned byte atype is a code that indicates if the type against which the object is being checked is an array type or a class type. It must take one of the following values or zero:

javacard:jcvm:7.5.54_invokeinterface

2017-05-13T04:09:38+00:00
7.5.54 invokeinterface Invoke interface method Format invokeinterface nargs indexbyte1 indexbyte2 method Forms invokeinterface = 142 (0x8e) Stack ..., objectref, [arg1, [arg2 ...]] -> ... Description The unsigned indexbyte1 and indexbyte2 are used to construct an index into the constant pool of the current package (

javacard:jcvm:7.5.55_invokespecial

2017-05-13T04:09:39+00:00
7.5.55 invokespecial Invoke instance method; special handling for superclass, private, and instance initialization method invocations Format invokespecial indexbyte1 indexbyte2 Forms invokespecial = 140 (0x8c) Stack ..., objectref, [arg1, [arg2

javacard:jcvm:7.5.56_invokestatic

2017-05-13T04:09:39+00:00
7.5.56 invokestatic Invoke a class (static) method Format invokestatic indexbyte1 indexbyte2 Forms invokestatic = 141 (0x8d) Stack ..., [arg1, [arg2 ...]] -> ... Description The unsigned indexbyte1 and indexbyte2 are used to construct an index into the constant pool of the current package (

javacard:jcvm:7.5.57_invokevirtual

2017-05-13T04:09:40+00:00
7.5.57 invokevirtual Invoke instance method; dispatch based on class Format invokevirtual indexbyte1 indexbyte2 Forms invokevirtual = 139 (0x8b) Stack ..., objectref, [arg1, [arg2 ...]] -> ... Description The unsigned indexbyte1 and indexbyte2 are used to construct an index into the constant pool of the current package (

javacard:jcvm:7.5.58_ior

2017-05-13T04:09:41+00:00
7.5.58 ior Boolean OR int Format ior Forms ior = 86 (0x56) Stack ..., value1.word1, value1.word2, value2.word1, value2.word2 -> ..., result.word1, result.word2 Description Both value1 and value2 must be of type int. The values are popped from the operand stack. An int result is calculated by taking the bitwise inclusive OR of value1 and value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.59_irem

2017-05-13T04:09:42+00:00
7.5.59 irem Remainder int Format irem Forms irem = 74 (0x4a) Stack ..., value1.word1, value1.word2, value2.word1, value2.word2 -> ..., result.word1, result.word2 Description Both value1 and value2 must be of type int. The values are popped from the operand stack. The int result is the value of the Java expression value1 - (value1 / value2) * value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.60_ireturn

2017-05-13T04:09:43+00:00
7.5.60 ireturn Return int from method Format ireturn Forms ireturn = 121 (0x79) Stack ..., value.word1, value.word2 -> [empty] Description The value must be of type int. It is popped from the operand stack of the current frame ( Section 3.5, Frames) and pushed onto the operand stack of the frame of the invoker. Any other values on the operand stack of the current method are discarded.

javacard:jcvm:7.5.61_ishl

2017-05-13T04:09:45+00:00
7.5.61 ishl Shift left int Format ishl Forms ishl = 78 (0x4e) Stack ..., value1.word1, value1.word2, value2.word1, value2.word2 -> ..., result.word1, result.word2 Description Both value1 and value2 must be of type int. The values are popped from the operand stack. An int result is calculated by shifting value1 left by s bit positions, where s is the value of the low five bits of value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.62_ishr

2017-05-13T04:09:45+00:00
7.5.62 ishr Arithmetic shift right int Format ishr Forms ishr = 80 (0x50) Stack ..., value1.word1, value1.word2, value2.word1, value2.word2 -> ..., result.word1, result.word2 Description Both value1 and value2 must be of type int. The values are popped from the operand stack. An int result is calculated by shifting value1 right by s bit positions, with sign extension, where s is the value of the low five bits of value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.63_istore

2017-05-13T04:09:46+00:00
7.5.63 istore Store int into local variable Format istore index Forms istore = 42 (0x2a) Stack ..., value.word1, value.word2 -> ... Description The index is an unsigned byte. Both index and index + 1 must be a valid index into the local variables of the current frame (

javacard:jcvm:7.5.64_istore_n

2017-05-13T04:09:47+00:00
7.5.64 istore_ Store int into local variable Format istore_ Forms istore_0 = 51 (0x33) istore_1 = 52 (0x34) istore_2 = 53 (0x35) istore_3 = 54 (0x36) Stack ..., value.word1, value.word2 -> ... Description Both and + 1 must be a valid indices into the local variables of the current frame (

javacard:jcvm:7.5.65_isub

2017-05-13T04:09:48+00:00
7.5.65 isub Subtract int Format isub Forms isub = 68 (0x44) Stack ..., value1.word1, value1.word2, value2.word1, value2.word2 -> ..., result.word1, result.word2 Description Both value1 and value2 must be of type int. The values are popped from the operand stack. The int result is value1 - value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.66_itableswitch

2017-05-13T04:09:48+00:00
7.5.66 itableswitch Access jump table by int index and jump Format itableswitch defaultbyte1 defaultbyte2 lowbyte1 lowbyte2 lowbyte3 lowbyte4 highbyte1 highbyte2 highbyte3 highbyte4 jump offsets... Offset Format offsetbyte1

javacard:jcvm:7.5.67_iushr

2017-05-13T04:09:50+00:00
7.5.67 iushr Logical shift right int Format iushr Forms iushr = 82 (0x52) Stack ..., value1.word1, value1.word2, value2.word1, value2.word2 -> ..., result.word1, result.word2 Description Both value1 and value2 must be of type int. The values are popped from the operand stack. An int result is calculated by shifting the result right by s bit positions, with zero extension, where s is the value of the low five bits of value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.68_ixor

2017-05-13T04:09:50+00:00
7.5.68 ixor Boolean XOR int Format ixor Forms ixor = 88 (0x58) Stack ..., value1.word1, value1.word2, value2.word1, value2.word2 -> ..., result.word1, result.word2 Description Both value1 and value2 must be of type int. The values are popped from the operand stack. An int result is calculated by taking the bitwise exclusive OR of value1 and value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.69_jsr

2017-05-13T04:09:51+00:00
7.5.69 jsr Jump subroutine Format jsr branchbyte1 branchbyte2 Forms jsr = 113 (0x71) Stack ... -> ..., address Description The address of the opcode of the instruction immediately following this jsr instruction is pushed onto the operand stack as a value of type returnAddress. The unsigned branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset, where the offset is (branchbyte1

javacard:jcvm:7.5.70_new

2017-05-13T04:09:53+00:00
7.5.70 new Create new object Format new indexbyte1 indexbyte2 Forms new = 143 (0x8f) Stack ... -> ..., objectref Description The unsigned indexbyte1 and indexbyte2 are used to construct an index into the constant pool of the current package (

javacard:jcvm:7.5.71_newarray

2017-05-13T04:09:54+00:00
7.5.71 newarray Create new array Format newarray atype Forms newarray = 144 (0x90) Stack ..., count -> ..., arrayref Description The count must be of type short. It is popped off the operand stack. The count represents the number of elements in the array to be created.

javacard:jcvm:7.5.72_nop

2017-05-13T04:09:55+00:00
7.5.72 nop Do nothing Format nop Forms nop = 0 (0x0) Stack No change Description Do nothing.

javacard:jcvm:7.5.73_pop

2017-05-13T04:09:55+00:00
7.5.73 pop Pop top operand stack word Format pop Forms pop = 59 (0x3b) Stack ..., word -> ... Description The top word is popped from the operand stack. The pop instruction must not be used unless the word contains a 16-bit data type.

javacard:jcvm:7.5.74_pop2

2017-05-13T04:09:57+00:00
7.5.74 pop2 Pop top two operand stack words Format pop2 Forms pop2 = 60 (0x3c) Stack ..., word2, word1 -> ... Description The top two words are popped from the operand stack. The pop2 instruction must not be used unless each of word1 and word2 is a word that contains a 16-bit data type or both together are the two words of a single 32-bit datum.

javacard:jcvm:7.5.75_putfield_t

2017-05-13T04:09:57+00:00
7.5.75 putfield_ Set field in object Format putfield_ index Forms putfield_a = 135 (0x87) putfield_b = 136 (0x88) putfield_s = 137 (0x89) putfield_i = 138 (0x8a) Stack ..., objectref, value -> ... OR ..., objectref, value.word1, value.word2

javacard:jcvm:7.5.76_putfield_t_this

2017-05-13T04:09:58+00:00
7.5.76 putfield__this Set field in current object Format putfieldthis index Forms putfield_a_this = 181 (0xb5) putfield_b_this = 182 (0xb6) putfield_s_this = 183 (0xb7) putfield_i_this = 184 (0xb8) Stack ..., value -> ... OR ...

javacard:jcvm:7.5.77_putfield_t_w

2017-05-13T04:09:58+00:00
7.5.77 putfield__w Set field in object (wide index) Format putfield_w indexbyte1 indexbyte2 Forms putfield_a_w = 177 (0xb1) putfield_b_w = 178 (0xb2) putfield_s_w = 179 (0xb3) putfield_i_w = 180 (0xb4) Stack ..., objectref, value

javacard:jcvm:7.5.78_putstatic_t

2017-05-13T04:10:06+00:00
7.5.78 putstatic_ Set static field in class Format putstatic_ indexbyte1 indexbyte2 Forms putstatic_a = 127 (0x7f) putstatic_b = 128 (0x80) putstatic_s = 129 (0x81) putstatic_i = 130 (0x82) Stack ..., value -> ... OR ..., value.word1, value.word2

javacard:jcvm:7.5.79_ret

2017-05-13T04:10:41+00:00
7.5.79 ret Return from subroutine Format ret index Forms ret = 114 (0x72) Stack No change Description The index is an unsigned byte that must be a valid index into the local variables of the current frame ( Section 3.5, Frames). The local variable at index must contain a value of type returnAddress. The contents of the local variable are written into the Java Card virtual machine's pc register, and execution continues there.

javacard:jcvm:7.5.80_return

2017-05-13T04:10:42+00:00
7.5.80 return Return void from method Format return Forms return = 122 (0x7a) Stack ... -> [empty] Description Any values on the operand stack of the current method are discarded. The virtual machine then reinstates the frame of the invoker and returns control to the invoker.

javacard:jcvm:7.5.81_s2b

2017-05-13T04:10:43+00:00
7.5.81 s2b Convert short to byte Format s2b Forms s2b = 91 (0x5b) Stack ..., value -> ..., result Description The value on top of the operand stack must be of type short. It is popped from the top of the operand stack, truncated to a byte result, then sign-extended to a short result. The result is pushed onto the operand stack.

javacard:jcvm:7.5.82_s2i

2017-05-13T04:10:44+00:00
7.5.82 s2i Convert short to int Format s2i Forms s2i = 92 (0x5c) Stack ..., value -> ..., result.word1, result.word2 Description The value on top of the operand stack must be of type short. It is popped from the operand stack and sign-extended to an int result. The result is pushed onto the operand stack.

javacard:jcvm:7.5.83_sadd

2017-05-13T04:10:44+00:00
7.5.83 sadd Add short Format sadd Forms sadd = 65 (0x41) Stack ..., value1, value2 -> ..., result Description Both value1 and value2 must be of type short. The values are popped from the operand stack. The short result is value1 + value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.84_saload

2017-05-13T04:10:45+00:00
7.5.84 saload Load short from array Format saload Forms saload = 38 (0x46) Stack ..., arrayref, index -> ..., value Description The arrayref must be of type reference and must refer to an array whose components are of type short. The index must be of type short. Both arrayref and index are popped from the operand stack. The short value in the component of the array at index is retrieved and pushed onto the top of the operand stack.

javacard:jcvm:7.5.85_sand

2017-05-13T04:10:46+00:00
7.5.85 sand Boolean AND short Format sand Forms sand = 83 (0x53) Stack ..., value1, value2 -> ..., result Description Both value1 and value2 are popped from the operand stack. A short result is calculated by taking the bitwise AND (conjunction) of value1 and value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.86_sastore

2017-05-13T04:10:47+00:00
7.5.86 sastore Store into short array Format sastore Forms sastore = 57 (0x39) Stack ..., arrayref, index, value -> ... Description The arrayref must be of type reference and must refer to an array whose components are of type short. The index and value must both be of type short. The arrayref, index and value are popped from the operand stack. The short value is stored as the component of the array indexed by index.

javacard:jcvm:7.5.87_sconst_s

2017-05-13T04:10:47+00:00
7.5.87 sconst_ Push short constant Format sconst_ Forms sconst_m1 = 2 (0x2) sconst_0 = 3 (0x3) sconst_1 = 4 (0x4) sconst_2 = 5 (0x5) sconst_3 = 6 (0x6) sconst_4= 7 (0x7) sconst_5 = 8 (0x8) Stack ... -> ..., Description Push the short constant (-1, 0, 1, 2, 3, 4, or 5) onto the operand stack.

javacard:jcvm:7.5.88_sdiv

2017-05-13T04:10:48+00:00
7.5.88 sdiv Divide short Format sdiv Forms sdiv = 71 (0x47) Stack ..., value1, value2 -> ..., result Description Both value1 and value2 must be of type short. The values are popped from the operand stack. The short result is the value of the Java expression value1 / value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.89_sinc

2017-05-13T04:10:49+00:00
7.5.89 sinc Increment local short variable by constant Format sinc index const Forms sinc = 89 (0x59) Stack No change Description The index is an unsigned byte that must be a valid index into the local variable of the current frame (

javacard:jcvm:7.5.90_sinc_w

2017-05-13T04:10:51+00:00
7.5.90 sinc_w Increment local short variable by constant Format sinc_w index byte1 byte2 Forms sinc_w = 150 (0x96) Stack No change Description The index is an unsigned byte that must be a valid index into the local variable of the current frame (

javacard:jcvm:7.5.91_sipush

2017-05-13T04:10:52+00:00
7.5.91 sipush Push short Format sipush byte1 byte2 Forms sipush = 19 (0x13) Stack ... -> ..., value1.word1, value1.word2 Description The immediate unsigned byte1 and byte2 values are assembled into a signed short where the value of the short is (byte1

javacard:jcvm:7.5.92_sload

2017-05-13T04:10:53+00:00
7.5.92 sload Load short from local variable Format sload index Forms sload = 22 (0x16) Stack ... -> ..., value Description The index is an unsigned byte that must be a valid index into the local variables of the current frame ( Section 3.5, Frames). The local variable at index must contain a short. The value in the local variable at index is pushed onto the operand stack.

javacard:jcvm:7.5.93_sload_n

2017-05-13T04:10:54+00:00
7.5.93 sload_ Load short from local variable Format sload_ Forms sload_0 = 28 (0x1c) sload_1 = 29 (0x1d) sload_2 = 30 (0x1e) sload_3 = 31 (0x1f) Stack ... -> ..., value Description The must be a valid index into the local variables of the current frame (

javacard:jcvm:7.5.94_slookupswitch

2017-05-13T04:10:55+00:00
7.5.94 slookupswitch Access jump table by key match and jump Format slookupswitch defaultbyte1 defaultbyte2 npairs1 npairs2 match-offset pairs... Pair Format matchbyte1 matchbyte2 offsetbyte1 offsetbyte2 Forms slookupswitch = 117 (0x75)

javacard:jcvm:7.5.95_smul

2017-05-13T04:10:56+00:00
7.5.95 smul Multiply short Format smul Forms smul = 69 (0x45) Stack ..., value1, value2 -> ..., result Description Both value1 and value2 must be of type short. The values are popped from the operand stack. The short result is value1 * value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.96_sneg

2017-05-13T04:10:56+00:00
7.5.96 sneg Negate short Format sneg Forms sneg = 72 (0x4b) Stack ..., value -> ..., result Description The value must be of type short. It is popped from the operand stack. The short result is the arithmetic negation of value, -value. The result is pushed onto the operand stack.

javacard:jcvm:7.5.97_sor

2017-05-13T04:10:58+00:00
7.5.97 sor Boolean OR short Format sor Forms sor = 85 (0x55) Stack ..., value1, value2 -> ..., result Description Both value1 and value2 must be of type short. The values are popped from the operand stack. A short result is calculated by taking the bitwise inclusive OR of value1 and value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.98_srem

2017-05-13T04:10:58+00:00
7.5.98 srem Remainder short Format srem Forms srem = 73 (0x49) Stack ..., value1, value2 -> ..., result Description Both value1 and value2 must be of type short. The values are popped from the operand stack. The short result is the value of the Java expression value1 - (value1 / value2) * value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.99_sreturn

2017-05-13T04:11:00+00:00
7.5.99 sreturn Return short from method Format sreturn Forms sreturn = 120 (0x78) Stack ..., value -> [empty] Description The value must be of type short. It is popped from the operand stack of the current frame ( Section 3.5, Frames) and pushed onto the operand stack of the frame of the invoker. Any other values on the operand stack of the current method are discarded.

javacard:jcvm:7.5.100_sshl

2017-05-13T04:12:09+00:00
7.5.100 sshl Shift left short Format sshl Forms sshl = 77 (0x4d) Stack ..., value1, value2 -> ..., result Description Both value1 and value2 must be of type short. The values are popped from the operand stack. A short result is calculated by shifting value1 left by s bit positions, where s is the value of the low five bits of value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.101_sshr

2017-05-13T04:12:09+00:00
7.5.101 sshr Arithmetic shift right short Format sshr Forms sshr = 79 (0x4f) Stack ..., value1, value2 -> ..., result Description Both value1 and value2 must be of type short. The values are popped from the operand stack. A short result is calculated by shifting value1 right by s bit positions, with sign extension, where s is the value of the low five bits of value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.102_sspush

2017-05-13T04:12:11+00:00
7.5.102 sspush Push short Format sspush byte1 byte2 Forms sspush = 17 (0x11) Stack ... -> ..., value Description The immediate unsigned byte1 and byte2 values are assembled into a signed short where the value of the short is (byte1

javacard:jcvm:7.5.103_sstore

2017-05-13T04:12:11+00:00
7.5.103 sstore Store short into local variable Format sstore index Forms sstore = 41 (0x29) Stack ..., value -> ... Description The index is an unsigned byte that must be a valid index into the local variables of the current frame (

javacard:jcvm:7.5.104_sstore_n

2017-05-13T04:12:12+00:00
7.5.104 sstore_ Store short into local variable Format sstore_ Forms sstore_0 = 47 (0x2f) sstore_1 = 48 (0x30) sstore_2 = 49 (0x31) sstore_3 = 50 (0x32) Stack ..., value -> ... Description The must be a valid index into the local variables of the current frame (

javacard:jcvm:7.5.105_ssub

2017-05-13T04:12:13+00:00
7.5.105 ssub Subtract short Format ssub Forms ssub = 67 (0x43) Stack ..., value1, value2 -> ..., result Description Both value1 and value2 must be of type short. The values are popped from the operand stack. The short result is value1 - value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5.106_stableswitch

2017-05-13T04:10:04+00:00
7.5.106 stableswitch Access jump table by short index and jump Format stableswitch defaultbyte1 defaultbyte2 lowbyte1 lowbyte2 highbyte1 highbyte2 jump offsets... Offset Format offsetbyte1 offsetbyte2 Forms stableswitch = 115 (0x73)

javacard:jcvm:7.5.107_sushr

2017-05-13T04:08:54+00:00
7.5.107 sushr Logical shift right short Format sushr Forms sushr = 81 (0x51) Stack ..., value1, value2 -> ..., result Description Both value1 and value2 must be of type short. The values are popped from the operand stack. A short result is calculated by sign-extending value1 to 32 bits^[13] and shifting the result right by s bit positions, with zero extension, where s is the value of the low five bits of value2. The resulting value is then truncated to a 16-bit result.…

javacard:jcvm:7.5.108_swap_x

2017-05-13T04:08:56+00:00
7.5.108 swap_x Swap top two operand stack words Format swap_x mn Forms swap_x = 64 (0x40) Stack ..., wordM+N, ..., wordM+1, wordM, ..., word1 -> ..., wordM, ..., word1, wordM+N, ..., wordM+1 Description The unsigned byte mn is used to construct two parameter values. The high nibble, (mn& 0xf0)

javacard:jcvm:7.5.109_sxor

2017-05-13T04:08:56+00:00
7.5.109 sxor Boolean XOR short Format sxor Forms sxor = 87 (0x57) Stack ..., value1, value2 -> ..., result Description Both value1 and value2 must be of type short. The values are popped from the operand stack. A short result is calculated by taking the bitwise exclusive OR of value1 and value2. The result is pushed onto the operand stack.

javacard:jcvm:7.5_the_java_card_virtual_machine_instruction_set

2017-05-13T04:11:01+00:00
7.5 The Java Card Virtual Machine Instruction Set Java virtual machine instructions are represented in this chapter by entries of the form shown in TABLE 7-1, an example instruction page, in alphabetical order. mnemonic Short description of the instruction.

javacard:jcvm:7._java_card_virtual_machine_instruction_set

2017-05-13T04:11:01+00:00
7. Java Card Virtual Machine Instruction Set A Java Card virtual machine instruction consists of an opcode specifying the operation to be performed, followed by zero or more operands embodying values to be operated upon. This chapter gives details about the format of each Java Card virtual machine instruction and the operation it performs.

javacard:jcvm:8._tables_of_instructions

2017-05-13T04:11:04+00:00
8. Tables of Instructions The following pages contain lists of the APDU instructions recognized by the Java Card platform, organized by opcode value ( TABLE 8-1) and by opcode mnemonic ( TABLE 8-2). dec hex mnemonic dec hex mnemonic 0 00 nop 47 2F sstore_0

javacard:jcvm:glossary

2017-05-13T04:11:04+00:00
Glossary active applet instance an applet instance that is selected on at least one of the logical channels. AID (application identifier) defined by ISO 7816, a string used to uniquely identify card applications and certain types of files in card file systems. An AID consists of two distinct pieces: a 5-byte RID (resource identifier) and a 0 to 11-byte PIX (proprietary identifier extension). The RID is a resource identifier assigned to companies by ISO. The PIX identifiers are assigned b…

javacard:jcvm:index

2017-05-13T04:11:06+00:00
Index A aaload, 1 aastore, 1 abstract, 1 AbstractMethodError, 1 access control, 1 remote interfaces, 1 aconst_null, 1 AID, 1 AID-based naming, 1 aload, 1 anewarray, 1 applet, 1 mulitselectable, 1 applet component, 1 applet firewall, 1 application identifier

javacard:jcvm:preface

2017-05-13T04:11:05+00:00
Preface Java Card technology combines a subset of the Java programming language with a runtime environment optimized for smart cards and similar small-memory embedded devices. The goal of Java Card technology is to bring many of the benefits of Java software programming to the resource-constrained world of devices such as smart cards.