BS ISO/IEC 20970:2002

Foreword
0 Introduction
   0.1 What is JEFF
        0.1.1 Benefits
1 Scope and normative references
   1.1 Scope
   1.2 Normative references
   1.3 Definitions
2 Data Types
   2.1 Basic Types
   2.2 Language Types
   2.3 Strings
        2.3.1 Definition
        2.3.2 Comparison
        2.3.3 Representation
   2.4 Specific Types
        2.4.1 Access Flags
        2.4.2 Type Descriptor
        2.4.3 Offsets
3 File Structure
   3.1 Definitions
        3.1.1 Fully Qualified Names
        3.1.2 Internal Classes and External Classes
        3.1.3 Fields and Method
        3.1.4 Field Position
   3.2 Conventions
        3.2.1 Notations
        3.2.2 Byte Order
        3.2.3 Alignment and Padding
   3.3 Definition of the File Structures
        3.3.1 File Header
        3.3.2 Class Section
               3.3.2.1 Class Header
               3.3.2.2 Interface Table
               3.3.2.3 Referenced Class Table
               3.3.2.4 Internal Field Table
               3.3.2.5 Internal Method Table
               3.3.2.6 Referenced Field Table
               3.3.2.7 Referenced Method Table
               3.3.2.8 Bytecode Block Structure
               3.3.2.9 Exception Table List
               3.3.2.10 Constant Data Section
        3.3.3 Attributes Section
               3.3.3.1 Attribute Type
               3.3.3.2 Class Attributes
               3.3.3.3 Attribute Table
        3.3.4 Symbolic Data Section
        3.3.5 Constant Data Pool
               3.3.5.1 Constant Data Pool Structure
               3.3.5.2 Descriptor
               3.3.5.3 Method Descriptor
        3.3.6 Digital Signature
4 Bytecodes
   4.1 Principles
   4.2 Translations
        4.2.1 The tableswitch Opcode
        4.2.2 The lookupswitch Opcode
        4.2.3 The new Opcode
        4.2.4 Opcodes With a Class Operand
        4.2.5 The newarray Opcode
        4.2.6 The multianewarray Opcode
        4.2.7 Field Opcodes
        4.2.8 Method Opcodes
        4.2.9 The ldc Opcodes
        4.2.10 The wide Opcodes
        4.2.11 The wide iinc Opcode
        4.2.12 Jump Opcodes
        4.2.13 Long Jump Opcodes
        4.2.14 The sipush Opcode
        4.2.15 The newconstarray Opcode
   4.3 Unchanged Instructions
        4.3.1 One-Byte Instructions
        4.3.2 Two-bytes Instructions
   4.4 Complete Opcode Mnemonics by Opcode
5 Restrictions

Gives dramatic savings of dynamic memory and execution time without sacrificing any of the flexibility usually attached to the use of non-pre-linked portable code. It is especially important to provide a complete solution to execute portable programs of which code size is bigger than the available dynamic memory.

This International Standard can be used with benefits on all kinds of platform.

This International Standard’s most immediate interest is for deploying portable applications on small footprint devices. This International Standard provides dramatic savings of dynamic memory and execution time without sacrificing any of the flexibility usually attached to the use of non-pre-linked portable code.

This International Standard is especially important to provide a complete solution to execute portable programs of which code size is bigger than the available dynamic memory.

This International Standard is also very important when fast reactivity of programs is important. By avoiding the extra-processing related to loading into dynamic memory and formatting classes at runtime, this International Standard provides a complete answer to the problem of class-loading slow-down.

These benefits are particularly interesting for small devices supporting financial applications. Such applications are often complex and relying on code of significant size, while the pressure of the market often imposes to these devices to be of a low price and, consequently, to be very small footprint platforms. In addition, to not impose unacceptable delays to customers, it is important these applications do not waste time in loading classes into dynamic memory when they are launched but, on the contrary, to be immediately actively processing the transaction with no delay. When using smart cards, there are also some loose real-time constraints that are better handled if it can be granted that no temporary freezing of processing can occur due to class loading.

This International Standard can also be of great benefit for devices dealing with real-time applications. In this case, avoiding the delays due to class loading can play an important role to satisfy real-time constraints.