Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 360: Connected Limited Device Configuration 8

Stage Access Start Finish
Final Approval Ballot   08 Apr, 2014 21 Apr, 2014
Proposed Final Draft Download page 27 Feb, 2014  
Public Review Ballot View results 01 Oct, 2013 14 Oct, 2013
Public Review Download page 27 Aug, 2013 26 Sep, 2013
Early Draft Review Download page 15 Apr, 2013 14 May, 2013
Expert Group Formation   30 Oct, 2012 15 Jan, 2013
JSR Review Ballot View results 16 Oct, 2012 29 Oct, 2012
JSR Review   02 Oct, 2012 15 Oct, 2012
Status: Active
JCP version in use: 2.9
Java Specification Participation Agreement version in use: 2.0


Description:
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:
  Public Communications
  Issue Tracking

Team

Specification Leads
  Michael Lagally Oracle
  Roger Riggs Oracle
Expert Group
  Stefano Andreani Aplix Corporation
: David Cheng
Gemalto M2M GmbH
: Thomas Lampart
  Werner Keil Nokia Corporation
: yiming zhao
North Sixty-One Ltd
: Erkki Rysä
  Oracle
: Michael Lagally
Oracle
: Roger Riggs
TOTVS
: David Campelo
  TOTVS
: Hernan Perrone
Thiago Galbiatti Vespa

Updates to the Original JSR

The following information has been updated from the original proposal.

2014.04.07:

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

The business and license terms are defined here:
Final Specification license
Final RI license
Attachment D to the Final RI license
TCK license.

2013.07.19:

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

  • JSR Approval and EG Formation: October 2012
  • Early Draft Review: April 2013
  • Public Review: Aug 2013
  • Final Draft: December 2013
  • Final Release: April 2014


Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Oracle

Name of Contact Person: Roger Riggs

E-Mail Address: roger.riggs@oracle.com

Telephone Number: +1 781 442 0539

Fax Number: +1 781 442 0395


Specification Leads: Michael Lagally, Roger Riggs, Oracle

E-Mail Address: michael.lagally@oracle.com, roger.riggs@oracle.com

Telephone Number: +49 89 1430 2620, +1 781 442 0539

Fax Number: +49 89 1430 1150, -


Initial Expert Group Membership:

Oracle
Aplix
Nokia
North Sixty-One Ltd
Stefano Andreani

Supporting this JSR:

Oracle
Aplix
ARM
Deutsche Telekom
Nokia
North Sixty-One Ltd
Vodafone
Siemens
Stefano Andreani
TOTVS



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:

  • Generic Types
  • A Simple Assertion Facility for debugging only
  • Annotations for the Java? Programming Language
  • Enumerations, Auto-boxing, enhanced for loops, varargs, and static import
  • Strings in switch
  • Binary literals
  • Multi-catch and precise re-throw
  • Improved type inference for generic instance creation
  • Try-with-resources

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:

  • InvokeDynamic will not be included
  • Support for Unicode 6 is not included

The new library features include:

  • Enumerations
  • Annotations - compile time only, no runtime support
  • Support for WeakReferences
  • Collections - updated to support generics
  • NIO API subset for buffers
  • NIO File IO subset
  • Logging API subset
  • CLDC APIs will be resynchronized to be aligned with Java SE 8
    • String
    • StringBuilder
    • Iterable interfaces

Generic Connection Framework (GCF):

  • The Generic Connection Framework (GCF) specification in CLDC will be consolidated and will reintegrate parts that were duplicated in the GCF specifications in CDC 1.1.2, MIDP and JSR 197.
  • The proposal is to specify a combined GCF specification that can be used with Java ME or Java SE.
  • The GCF specification should be binary backward compatible with previous versions of CLDC, MIDP, and JSR 197.

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:

  • java.lang
  • java.lang.ref
  • java.io
  • java.util
  • java.security
  • java.nio buffers
  • javax.microedition.io [combined GCF specification]

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.

  • JSR Approval and EG Formation: October 2012
  • Early Draft Review: Dec 2012
  • Public Review: Apr 2013
  • Final Release: Sept 2013

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

  • JSR Approval and EG Formation: October 2012
  • Early Draft Review: April 2013
  • Public Review: Aug 2013
  • Final Draft: December 2013
  • Final Release: April 2014

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).

N/A

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

The business and license terms are defined here: Final Specification license
Final RI license
Attachment D to the Final RI license
TCK license.

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

The business and license terms are defined here:
Final Specification license
Final RI license
Attachment D to the Final RI license
TCK license.

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?

See this JSR's java.net project for the issue tracker based on Jira.

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.