Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 290: JavaTM Language & XML User Interface Markup Integration

Stage Access Start Finish
Proposed Final Draft 2 Download page 01 May, 2009  
Proposed Final Draft Download page 18 Aug, 2008  
Public Review Ballot View results 11 Mar, 2008 17 Mar, 2008
Public Review Download page 15 Feb, 2008 17 Mar, 2008
Early Draft Review Download page 12 Mar, 2007 11 Apr, 2007
Expert Group Formation   31 Jan, 2006  
JSR Review Ballot View results 17 Jan, 2006 30 Jan, 2006
Status: Dormant
JCP version in use: 2.6
Java Specification Participation Agreement version in use: 2.0

This JSR enables creation of Java ME applications which combine Web UI markup technologies with Java code. The intent is to leverage the W3C Compound Document Format (CDF) specification.

Please direct comments on this JSR to the Spec Lead(s)

Specification Leads
  Jean-Yves Bitterlich Oracle
Expert Group
  Cisco Systems Motorola Nokia Corporation
  Oracle SAGEM Communication Samsung Electronics Corporation
  Sun Microsystems, Inc. Vodafone Group Services Limited

This JSR has been Dormant
Reason: The Specification Lead chose to list this JSR as dormant in August 2012.

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2007.02.19: EDR: Q1 2007.
- PR: Q2 2007.
- FAB: Q3/Q4 2007.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Sun Microsystems, Inc

Name of Contact Person: Bartley Calder

E-Mail Address:

Telephone Number: +1 408 276 6733

Fax Number: +1 408 276 7201

Specification Lead: Vincent Hardy

E-Mail Address:

Telephone Number: +33 6 83 17 62 83

Fax Number: +1 408 276 7209

Initial Expert Group Membership:

Sun Microsystems, Inc

Supporting this JSR:

Sun Microsystems, Inc
Ericsson Mobile Platforms

Section 2: Request

2.1 Please describe the proposed Specification:

This specification will enable the creation of Java ME applications which combine the ease of authoring and graphical richness of Web UI technologies (such as XHTML Basic and SVG Tiny) with the power, flexibility, and breadth of the Java ME platform. The APIs and conventions defined by this JSR will provide for three styles of Java and XML UI markup integration:

1) cross-referencing between markup and Java ME code
2) embedding a Java ME component within markup (e.g. a browser page)
3) embedding UI markup data within a Java ME application

This specification will provide a binding to the Compound Document Format (CDF []) markups such as WICD (Web Interaction Compound Document) Mobile 1.0 ( The specification will define an API to load, manipulate, interact and render XML markups for user interfaces. It will follow models of DOM API definitions used by JSR 226 and JSR 280. The Expert Group will collaborate with the W3C CDF Working Group where appropriate, for example to provide review comments on the CDF specifications or to request comments on its own specification.

The specification will also define the conventions that Java archives should follow to let tools bind Java handlers to events happening in XML markups.

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

The platforms specifically addressed for this JSR are CLDC/MIDP and CDC/PBP, however this JSR may also be supported on other Java ME platforms. The expert group will also insure that the API is efficiently implementable on Java SE.

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.

The platforms specifically addressed for this JSR are CLDC/MIDP and CDC/PBP, however this JSR may also be supported on other Java ME platforms. The expert group will also insure that the API is efficiently implementable on Java SE. While this JSR is submitted as a Java ME JSR we expect implementations to become available for both desktop and mobile platforms. We encourage EG participation by desktop oriented partners.

2.4 Should this JSR be voted on by both Executive Committees?

No, only the Java ME committee.

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

This JSR responds to a market need in the mobile device space for the ability to develop applications by leveraging the skills of multiple types of developers, including graphics artists who work with graphical tools, markup and script authors, and Java coders. The goal is to enable rich UIs coupled with computational tasks beyond the scope of scripting, all executing on the mobile client. This solution could also apply to desktop clients as well and the interfaces developed by this JSR should apply there as well, but the activity and interest around the CDF work is strong among mobile developers at this time.

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

JSR 226 and JSR 287 focus on SVG-T and this JSR should coordinate with the new JSR 287 EG and follow their lead on SVG specific issues and ensure that functionality defined in this expert group complements the JSR-287 specification. JSR 280 will define generic uDOM APIs and this JSR should coordinate with them and generic DOM APIs should be defined by that EG. This JSR will focus on user agent issues and DOM APIs specific to CDF. It will also define tooling conventions for integrating markup and Java code. It may also address other issues related to combining markup and Java, such as a Java Web Start like capability for Java ME.

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

This specification will provide a binding to the Compound Document Format (CDF []) markups. The specification will define an API to load, manipulate, interact and render XML markups for user interfaces. It will follow models of DOM API definitions used by JSR 226 and JSR 280.

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

org.w3c.tbd for DOM APIs javax.microedition.tbd for other APIs

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


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


2.11 Are there any internationalization or localization issues?


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


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

Early Draft Review: Q2/2006
Public Review Draft: Q3/2006
Final specification: Q4/2006
Note that this information has been updated from the original JSR.

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

A kickoff face-to-face meeting, weekly concalls, and additional face-to-face meetings as needed.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

An observers alias will be created and monthly status updates will be sent to the alias. Members of the expert group who wish to be included on the alias can do so and participate in discussions with the observers.

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.

The RI will be delivered in two bundles to run on Sun's WTK, based on CLCD 1.1 and MIDP 2.x, and on Sun's CDC toolkit, based on CDC 1.1 and PBP 1.1. The TCK will cover both CLDC/MIDP and CDC/FP/PBP.

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.

Sun Microsystems, Inc., will make the TCK and RI available for licensing separately:
Sun will make the TCK available on a stand-alone basis at no charge, without support or any trademark license rights, to qualified not-for- profit entities (including not-for-profit academic institutions) and qualified individuals engaged in efforts to create compatible implementations of the Specification. All other use is deemed commercial.
Sun will also make the TCK available for commercial use for an initial flat fee and annual maintenance fee.
Sun will make a binary version of the Reference Implementation available at no cost to TCK licensees for the purpose of configuring and supporting the TCK. No right to redistribute the reference implementation is provided.

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.

Compound Document Formats:
Scalable Vector Graphics Tiny version 1.2:
XML Events:
Document Object Model Level 3 Events:

3.2 Explanation of how these items might be used as a starting point for the work.

The interfaces defined by this JSR must be compatible and interoperable with the above specifications. The CDF spec is still under development and this EG will track that spec and possibly provide feedback to the CDF WG. We will try to recruit some members of the CDF WG to join this EG.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.