Find JSRs
Submit this Search


Ad Banner
 
 
 
 
JSRs: Java Specification Requests
JSR 202: JavaTM Class File Specification Update

Updates to the Original JSR

The following updates have been made to the original request.

2010.02.15:

Maintenance Lead: Alex Buckley
E-Mail Address: alex.buckley@oracle.com
Telephone Number: +1 408 276 3065

2006.10.24

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

This RI and TCK for this JSR will be delivered as part of RI and TCK for Java SE 6 (JSR 270), respectively. The proposed Java SE 6 licensing terms are available here: http://jcp.org/en/jsr/detail?id=270

2006.10.12

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

We plan to include the RI and TCK as part of Java SE 6.

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

This RI and TCK for this JSR will be delivered as part of RI and TCK for Java SE 6 (JSR 270), respectively. The proposed Java SE 6 licensing terms are available here

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Sun Microsystems, Inc

Name of Contact Person: Graham Hamilton

E-Mail Address: graham.hamilton@sun.com

Telephone Number: +1 408 276 7102

Fax Number:


Specification Lead: Gilad Bracha

E-Mail Address: gilad.bracha@sun.com

Telephone Number: +1 408 276 7025

Fax Number:


Note that this information has been updated from this original proposal.

Initial Expert Group Membership:

Supporting this JSR:

Apple Computer
HP
IBM
Oracle
SavaJe Technologies



Section 2: Request

2.1 Please describe the proposed Specification:

This JSR will revise the JavaTM Virtual Machine Specification by making some incremental updates to the Java class file specification. This work is targeted at the J2SE 1.5 "Tiger" release.

The four planned updates are:

  • Adding split verifier support.

    The split verifier architecture that was introduced in CDLC via JSR-030 and JSR-139 offers significant improvements over the classic JVM verifier, including reducing verification time. It appears useful to allow this verification format to be used with J2SE.

  • Increasing various size limits.

    Some applications that automatically generate JavaTM source code (such as JSP compilers) have reported encountering problems due to implicit size limits in the current class file format. This JSR will increase relevant limits where needed.

  • Adding support for class literals.

    Since JDK 1.1 the JavaTM language has included support for accessing class literals though expressions such as "MyClassName.class". However there has been no direct support for this in the class file format and it appears that adding class file support will allow significantly more efficient access to class literals.

  • Minor changes to support JavaTM language changes in Tiger.

    The JavaTM language changes that are planned for Tiger do not require any major JavaTM virtual machine changes. However, there may be some minor changes such as adding additional classfile attributes or flag bits. These JVM specification changes will be handled through this JSR, after consultation with the specification leads for the relevant language JSRs.

These four changes will be implemented as incremental updates to the existing class file format. Full compatibility will be maintained for existing class files and the existing class file format.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

J2SE.

2.3 What need of the Java community will be addressed by the proposed specification?

This JSR will provide some useful updates to the JavaTM class file specification as described in Sections 2.1 and 2.5.

2.4 Why isn't this need met by existing specifications?

The current JVM specification needs to be revised to add these features.

2.5 Please give a short description of the underlying technology or technologies:

The existing J2SE class file verifier needs to execute a complex iterative dataflow algorithm at run-time to verify the correctness of a target class file. This algorithm is expensive in both time and space and is also difficult to fully specify.

As part of the development of the Connected Limited Device Confguration (CLDC) the CLDC team wished to avoid the time and space penalties of performing full verification within small devices. They therefore developed a "split verifier" which split the verification process into two phases:

  • The first phase can be performed when the class file is being created. It performs a scan of the class file and adds additional "StackMap" attributes to the class file for use by the second phase.

  • The second phase is performed at run-time. The run-time verifier uses the additional StackMap attributes to perform the final class file verification efficiently. The run-time verifier does not rely on the StackMap attributes being valid and will detect and reject any false information.

The discovery of this "split verifier" technology has come as a pleasant surprise. It significantly simplifies the security-critical run-time verification phase and it also accelerates class-loading. These benefits are useful well beyond CLDC and and it appears beneficial to allow the split-verifier technology to be used with J2SE.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

Not applicable.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No

2.8 Are there any security issues that cannot be addressed by the current security model?

No

2.9 Are there any internationalization or localization issues?

No

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No other specifications will be affected.

There will be full support for backward compatibility. Old format class files will still be supported by new VMs.

2.11 Please describe the anticipated schedule for the development of this specification.

It is intended that this JSR will be delivered as part of the J2SE 1.5 "Tiger" release.

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

It is anticipated that most discussions will be by email.

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

This JSR will be delivered as part of J2SE 1.5 "Tiger".

NOTE that this section has been updated from this original request.

2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A.

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

This JSR will be delivered as part of J2SE 1.5 "Tiger". The proposed J2SE 1.5 licensing terms are available at J2SE 1.5 licensing terms.

NOTE that this section has been updated from this original request.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

A detailed paper on the split-verifier techology "CLDC Byte Code Typechecker Specification" by Gilad Bracha, Tim Lindholm, Wei Tao, and Frank Yellin is included as Appendix 1 within the draft http://jcp.org/en/jsr/detail?id=139 CLDC 1.1 specification which is currently in JCP Public Review.