Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 287: Scalable 2D Vector Graphics API 2.0 for Java METM

Stage Access Start Finish
Final Release Download page 10 Dec, 2009  
Final Approval Ballot View results 17 Nov, 2009 30 Nov, 2009
Proposed Final Draft 3 Download page 12 Dec, 2008  
Proposed Final Draft 2 Download page 02 May, 2008  
Proposed Final Draft Download page 31 Aug, 2007  
Public Review Ballot View results 15 May, 2007 21 May, 2007
Public Review Download page 16 Apr, 2007 21 May, 2007
Early Draft Review Download page 04 Dec, 2006 18 Jan, 2007
Expert Group Formation   20 Dec, 2005 10 Oct, 2006
JSR Review Ballot View results 06 Dec, 2005 19 Dec, 2005
Status: Final
JCP version in use: 2.7
Java Specification Participation Agreement version in use: 2.0

This specification will define an optional package for rendering enhanced 2D vector graphics and rich media content based on select features from SVG Mobile 1.2, with primary emphasis on MIDP.

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

Specification Leads
  Juha Eskelinen Nokia Corporation
  Kimmo Loytana North Sixty-One Ltd
Expert Group
  Advanced Micro Devices, Inc Aplix Corporation Comcast Cable Communications Management, LLC
  Cox Communications, Inc. Ericsson AB Huone, Inc
  Hybrid Graphics Ltd. Ikivo AB Monotype Imaging Inc
  Motorola Nokia Corporation North Sixty-One Ltd
  NVIDIA Open Text Corporation Orange France SA
  Philips Electronics UK Ltd Sun Microsystems, Inc. TVWORKS, LLC
  XCE Co., Ltd. Zuschlag, Jesper

Updates to the Original JSR

The following information has been updated from the original request.

2012.08.22: The following section has been updated.

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

- Available free of charge to qualified not-for-profit organizations and individuals in accordance with the JSPA, solely for developing and testing their own implementations and not allowing to test any third party or commercial for-profit implementations.
- The TCK is licensed, in line with the MSA licensing principles, with a flat fee of USD 50 000 for a license term of 3 years. This includes all maintenance updates and releases, if any. The license will be worldwide, non-exclusive and will be granted on an AS IS basis without any warranties or indemnities given and with the exclusion of all indirect and consequential damages. Major new releases, from new follower JSR, are subject to a separate license fee.
- The license grant will be for a term of not less than three (3) years.
- A license allowing licensees to test implementations on behalf of third parties as a free or for-fee commercial service under certain conditions shall be available. This right may result in a higher license fee.

2012.08.21: North Sixty-One has become the co-Maintenance Lead.

Maintenance Lead: Kimmo Löytänä

E-Mail Address:

Telephone Number: -

Fax Number: -


Specification Lead: Juha Eskelinen

E-Mail Address:

Telephone Number: -

Fax Number: -


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

EG Formation: May 2006
Early Draft Review: November 2006
Public Review: February 2007
Proposed Final Draft: April 2007
Final Approval Ballot: August 2007

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Nokia Corporation

Name of Contact Person: Suresh Chitturi

E-Mail Address:

Telephone Number: +1 972 894 6758

Fax Number: +1 972 894 5937

Specification Lead: Suresh Chitturi

E-Mail Address:

Telephone Number: +1 972 894 6758

Fax Number: +1 972 894 5937

Initial Expert Group Membership:

Nokia Corporation
Ericsson AB

Supporting this JSR:

Nokia Corporation
Ericsson AB

Section 2: Request

2.1 Please describe the proposed Specification:

This specification will define an optional package for rendering enhanced 2D vector graphics and rich media content based on select features from SVG Mobile 1.2 for Java ME platform, with primary emphasis on MIDP. This API will be designed as an extension to JSR 226, and therefore must remain to be fully backwards compatible with JSR 226 applications and Scalable Vector Graphics (SVG) rendering model. The primary use cases for this API are interactive maps with rich graphics, scalable user interfaces, rich media services, games, entertainment, and other compelling graphics applications aimed at mobile devices.

The API is targeted at mass market devices that typically have limited processing power and memory. The API shall be defined such that implementations on these target devices are feasible and allow utilization of underlying native SVG implementations of the device.

The scope of the API should include the following:

  1. Extend Features in JSR 226
    1. Add the ability to create and modify animations. Not having the ability to create or modify animations makes application development using 226 a bit of a challenge.
    2. DOM serialization to allow compelling use cases. Note: this should be designed to avoid large performance overhead, and avoid any security issues.
  2. Support for select SVG Mobile 1.2 features

    SVG Mobile 1.2 is the next-generation profile for scalable vector graphics. It brings a substantial set of compelling features such as support for opacity, gradients, advanced text rendering, and embedded multimedia (audio, video). The features to be included from the SVG Mobile 1.2 specification must be carefully chosen not to compromise the important requirements for this JSR such as high performance and low implementation footprint, especially for the low-end mass market devices.

  3. Support for additional uDOM APIs from SVG Mobile 1.2

    Currently JSR 226 supports only a subset of uDOM as defined in SVG Mobile 1.2 specification. The proposed JSR will expand the support of uDOM subset to support new interfaces that are only relevant to the use cases envisaged in this document. It is important to note that during this process of subsetting, any changes or issues that may affect the SVG Mobile 1.2 specification will be coordinated with W3C SVG working group to ensure compatibility between JCP and W3C specifications. For the generic XML DOM API part, the work will be closely coordinated with JSR 280 in order to have a common solution for the XML DOM API.

  4. Support of Rich Media content Streaming

    Rich media content update and streaming is gaining high importance in the mobile domain, especially with new work-items in both OMA and 3GPP standards. Such technology is also important for Java ME platform to allow or offer rich media solutions based on SVG Mobile 1.2 which already specifies mechanisms to embed and display rich media data such as graphics, video, audio and text. At the minimum, this JSR intends to define a scene update syntax and APIs to allow rich media services or applications to dynamically update the content on the client terminal with minimum processing overhead.

  5. Advanced immediate-mode rendering APIs (compatible with OpenVG)

    OpenVG defines a standard 2D graphics for hardware acceleration, particularly for vector graphics content such as SVG, Flash, and GUI. We would like to investigate possibilities of defining such an immediate-mode API that can take advantage of this standard.This work however, needs to be coordinated with other Java ME JSR expert groups to minimize overlaps.

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

The API is targeting Java Micro Edition and must be usable on both CLDC and CDC based platforms and with MIDP as well as with other Java Micro Edition Profiles.

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.

Although, the primary target platform is Java ME and MIDP, the design of the API should be implementable or take into account support for higher profiles with other UI toolkits and Java SE as much as possible.

However, it is important to note that API design and supported features must not compromise core requirements such as high performance and low footprint, especially for the resource limited mass market devices.

Should this JSR be voted on by both Executive Committees?


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

This specification will define a platform for developing advanced vector graphics applications such as interactive maps with rich graphics, scalable user interfaces, rich media services, games, entertainment, and other compelling graphics applications. Today, there already exist some non-standard methods and technologies to develop such applications; and this certainly does not help in the wide spread adoption of these technologies, particularly in the mobile Java community.

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

JSR 226 - defines an API for rendering scalable graphics content for J2ME platform, but there are new and more advanced use cases and requirements as described in this proposal. Therefore we see a need to have a new successor version for this JSR. However, JSR 226 does provide a good basis for developing this successor standard. This approach not only builds on top of existing solutions but also avoids fragmentation.

JSR 135/234 ? Mobile Media API ? defines a high-level control API for different media types, but does not address the control of vector graphics formats with other media types.

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

Rich mobile multimedia (also referred to as compound media, which combines several media types such as graphics, text, audio, video) services are gaining increased attention in the mobile industry. This is largely due to the available 3rd generation networks with high data rates, and the rising demand from the end users to be able to view advanced multimedia content including rich, scalable, animated, and interactive graphics combined together with other media.

JSR 226 already provides some capabilities to achieve this functionality, however there is strong desire in the mobile community to extend this API to support advanced features such as support for select SVG Mobile 1.2 features, additional uDOM APIs from SVG Mobile 1.2, and functionality for streaming of rich media content.

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


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?

None known or anticipated.

2.11 Are there any internationalization or localization issues?

International text/font support is system dependent.

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

None known or anticipated.

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

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

EG Formation: January 2006
Early Draft Review: April 2006
Public Review: July 2006
Proposed Final Draft: October 2006
Final Approval Ballot: March 2007

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

E-mail, teleconference, and face-to-face discussions as needed and as appropriate.

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.

JSR community page is used to provide the community with regular updates of the draft specifications and information about the current topics and issues of the Expert Group.

The Expert Group may also use the list to request feedback on key issues facing the group.

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 Reference Implementation (RI) and Technology Compatibility Kit (TCK) will be delivered separately and as stand-alone.

See the business terms section for more details.

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.

These terms only represent the initial commercial terms to be used and remain subject to the execution of final legal agreements covering the subject matter hereof to be determined by Nokia at its sole discretion. We will license to all interested parties. Independent implementations will be allowed - TCK and RI will be licensed separately.

For the TCK we will charge a single one-time fee of max US $50,000 and an annual maintenance fee, max US $20,000 for a term of four years. The TCK will include both the binary environment and the source code for the test suite. The maintenance fee covers limited basic support, first level TCK appeals process, bug fixes when available and updates, which are due to changes in the Specification. Major new releases (esp. from new follower JSR) might be subject to an additional single one-time fee.

Using the TCK for testing of implementations on behalf of third parties will be allowed, though, be subject to a higher fee, which is capped at the sum of license fees due in accordance with license fees as described above in this section, if the third parties would have directly licensed the TCK from Nokia.

The RI is made available free of charge in binary form.

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.

In addition to the JSRs mentioned in Section 2.4, the following references may be applicable:

  • JSR-226 -
  • Mobile SVG 1.2 specification -
  • OMA Rich Media Environment -
  • 3GPP Dynamic and Interactive Multimedia Scenes-

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

    These items will be used for general reference purposes.