 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 287: Scalable 2D Vector Graphics API 2.0 for Java METM
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.
TCK: 2012.08.21: North Sixty-One has become the co-Maintenance Lead. Maintenance Lead: Kimmo Löytänä E-Mail Address: jsr287 Telephone Number: - Fax Number: - 2009.06.24: Specification Lead: Juha Eskelinen E-Mail Address: juha.eskelinen Telephone Number: - Fax Number: - 2006.10.27: 2.13 Please describe the anticipated schedule for the development of this specification.EG Formation: May 2006Early 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: suresh.chitturi Telephone Number: +1 972 894 6758 Fax Number: +1 972 894 5937 Specification Lead: Suresh Chitturi E-Mail Address: suresh.chitturi Telephone Number: +1 972 894 6758 Fax Number: +1 972 894 5937 Initial Expert Group Membership: Nokia Corporation Supporting this JSR: Nokia Corporation 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:
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?No. 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.)javax.microedition.m2g 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?None 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 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).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.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:
|
