JSRs: Java Specification Requests
JSR 360: Connected Limited Device Configuration 8
JCP version in use: 2.8
Java Specification Participation Agreement version in use: 2.0
CLDC 8 will be an evolutionary update to CLDC 1.1.1 to bring the VM, Java Language, and libraries up to date with Java SE 8.
Expert Group Transparency:
Section 1. Identification
Submitting Member: Oracle
Name of Contact Person: Roger Riggs
E-Mail Address: roger.riggs
Telephone Number: +1 781 442 0539
Fax Number: +1 781 442 0395
Specification Leads: Michael Lagally, Roger Riggs, Oracle
E-Mail Address: michael.lagally
Telephone Number: +49 89 1430 2620, +1 781 442 0539
Fax Number: +49 89 1430 1150, -
Initial Expert Group Membership:
Supporting this JSR:
Section 2: Request
2.1 Please describe the proposed Specification:
The Java ME CLDC specification is to be updated with VM, Java Language, and libraries and features to be aligned with Java SE 8 while retaining the focus on small mobile and embedded target devices.
CLDC 1.1 was approved in 2003, and since then the Java VM, Java Language and libraries have been extended with new features that promote more efficient and expressive programming. The original 2001 constraints on size and performance have increased slightly as Java continues to be used in devices with very limited memory. The original sub-setting of libraries and behavior has largely been effective but some limited additions are needed.
The goal of this update is to bring the power and flexibility of the Java 8 Language features to Java ME with limited additions to the APIs and VM to maintain the small footprint while promoting a consistent development environment and increased developer productivity.
The new language features include:
The virtual machine features will be primarily continue the CLDC JVM specification based on JVMS 2 plus support for the LDC bytecode support for class literals.
Due to size limitations and complexity some features of JVMS 2 will not be included:
The new library features include:
Generic Connection Framework (GCF):
Note that while APIs may be adopted from Java SE 8, no new platform API definitions are planned in this JSR.
This revision will be binary backward compatible with previous releases of the CLDC specification.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
Java Platform, Micro Edition (Java ME) Connected Limited Device Configuration for small embedded and mobile devices.
2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.
CLDC will continue to be a subset of Java SE.
2.4 Should this JSR be voted on by both Executive Committees?
The ME Executive Committee should vote on this request. Some elements may be of interest to both Executive Committees but the resulting specifications are applicable to the Java ME community.
2.5 What need of the Java community will be addressed by the proposed specification?
This update to the CLDC specification will enable developers for Java ME to more fully use the functions of the Java Language, VM and libraries. This will remove barriers to adoption currently caused by differences in APIs, VM features, and tool chains. Library and module re-use currently is limited because language or library features that are not present in the current Java ME specifications.
2.6 Why isn't this need met by existing specifications?
Existing specifications for these functions have already been developed but need to be made available to Java ME.
2.7 Please give a short description of the underlying technology or technologies:
All of the underlying technologies, Java VM, Java Language, and Java libraries have been specified by Java SE 8 and are already in use on other platforms. This proposal brings an appropriate subset of features to mobile and embedded devices.
2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)
Most packages and classes are subsets of Java SE 8, javax.microedition is upgraded from the CLDC 1.1.1 spec:
2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?
There are no new dependencies, all of the technologies needed to support the VM, language, and library features are already in use in various Java runtimes.
2.10 Are there any security issues that cannot be addressed by the current security model?
The current CLDC 1.1.1 security model supports Permission based checks and there are no new issues identified at this time.
2.11 Are there any internationalization or localization issues?
None identified at this time.
2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
The specification for CLDC is being revised to produce a newer version. The previous versions are still applicable to many use cases.
Other optional packages and specifications can be independently updated to take advantage of language features such as generics.
Consideration should be given to updating the MSA specification to use the updated CLDC specification.
2.13 Please describe the anticipated schedule for the development of this specification.
2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.
The primary means of communication will be email, conference calls, the document archive and issue tracker. An initial conference call will be used to establish an effective working model and further meetings will be scheduled as needed. We will solicit feedback from the community.
2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:
The updated JCP processes defined by JCP 2, version 2.8 will be used to promote transparency and participation. All discussions will be carried out or reported on a public mailing list, and all materials generated by the EG will be published. The Expert Group will publish drafts for review by the community at convenient points during the development of the specification. The community will be encouraged to provide feedback through a public alias, and formal comments will be logged and publicly responded to. See this JSR's java.net project for details.
2.16 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.
Standalone RI and TCK will be available.
2.17 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).
2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.
See this JSR's java.net project for details of the email lists, discussions groups.
2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?
Updated on 13 November 2012: http://javafx-jira.kenai.com/browse/MESPEC/component/10660 (requires free JIRA account)
2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.
See this JSR's java.net project for details of the document archive.
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.
Existing specifications, implementations and conformance tests will be used to the fullest extent possible.
3.2 Explanation of how these items might be used as a starting point for the work.
The Java VM, Java Language, and library updates will be reused from Java SE to get the highest leverage and reusability and clean subset relationships. This is particularly desirable and necessary for conformance tests.