Printed: Mar 28, 2024
From: http://www.jcp.org/en/jsr/detail?id=226
|
Specification Leads | |||
Juha Eskelinen | Nokia Corporation | ||
Kimmo Loytana | North Sixty-One Ltd | ||
Expert Group | |||
Aplix Corporation | BenQ Corporation | Ericsson AB | |
Esmertec AG | Espial Group, Inc. | Girow, Andrew | |
iaSolution Inc. | IBM | Ikivo AB | |
In-Fusio SA | Motorola | Nokia Corporation | |
North Sixty-One Ltd | SAS Institute Inc. | Sony Ericsson Mobile Communications AB | |
Sun Microsystems, Inc. | Symbian Ltd | Texas Instruments Inc. |
Updates to the Original Java Specification Request (JSR)
The following information has been updated from the original proposal, as follows:
2015.04.13:
The Maintenance Lead from Nokia Corporation has changed to Adamu Haruna.
Maintenance Lead: Adamu Haruna
E-Mail Address: adamu.haruna
Telephone Number: -
Fax Number: -
2012.08.22:
The following section has been updated.
2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
TCK:
- 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: jsr226
Telephone Number: -
Fax Number: -
2009.06.24
The Maintenance Lead was changed to Juha Eskelinen.
Maintenance Lead: Juha Ekselinen
E-Mail Address: juha.eskelinen
Telephone Number: -
Fax Number: -
2009.03.06
The Maintenance Lead was changed to Jarmo Korhonen.
Maintenance Lead: Jarmo Korhonen
E-Mail Address: jarmo.j.korhonen
Telephone Number: +358 7180 21022
Fax Number: +358 7180 70530
Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification
Submitting Member: Nokia Corporation
Name of Contact Person: Tolga Capin
E-Mail Address: tolga.capin@nokia.com
Telephone Number: +1 972 894 4651
Fax Number: +1 972 894 4589
Specification Lead: Tolga Capin & Suresh Chitturi
E-Mail Address: tolga.capin@nokia.com & suresh.chitturi@nokia.com
Telephone Number: +1 972 894 4651 & +1 972 894 6758
Fax Number: +1 972 894 4589 & +1 972 894 5937
Initial Expert Group Membership:
* Nokia Corporation
* Motorola
* Sun Microsystems
* Symbian
* Texas Instruments
Supporting this JSR:
* Nokia Corporation
* Motorola
* Siemens
* Sun Microsystems
* Symbian
* Texas Instruments
Section 2: Request
This specification will define an optional package API for rendering scalable 2D vector graphics, including image files in W3C Scalable Vector Graphics (SVG) format. The API is targeted for J2ME platform, with primary emphasis on MIDP. The main use cases for this API are map visualization, scalable icons, and other advanced graphics applications.
The main target platform of this API is J2ME/CLDC/MIDP. The API is targeted at CLDC class devices that typically have very little processing power and memory, and no hardware support for 2D graphics or floating point arithmetic. The API shall allow utilization of native 2D graphics features of the device when applicable.
The API should include:
* Ability to load and render external 2D vector images, stored in the W3C SVG Tiny format.
* Rendering of 2D images that are scalable to different display resolutions and aspect ratios.
The EG shall consider possibilities for subsetting from Java 2D API / JSR-209. Where subsetting is not possible, the API should be efficiently implementable on top of the Java 2D API / JSR-209. The API should be rich enough to support an SVG Tiny implementation.
The API is proposed to be an optional package to be used together with several J2ME profiles. Therefore, the design of the API should take into account support for both MIDP / LCDUI and PP/PBP / AWT as much as possible.
This API will use floating point data types in the API methods in order to provide a clean and easy to use API. However, it should be possible to implement this API using fixed-point arithmetic underneath the API layer. Because floating point data types are used in the API, it requires CLDC 1.1 as the minimum configuration.
The target footprint for this API including only the wrappers to native code should be under 30KB, assuming a level of support of native 2D graphics functionality on the device.
This specification will bring the following capabilities to the mobile terminals with J2ME/CLDC 1.1 support:
* Ability to load and render external 2D vector images, stored in the W3C SVG Tiny format. The API may be extendable to support other formats.
* Low-level rendering API for 2D images that are scalable to different display resolutions and aspect ratios.
Current proposals for integration of 2D into a Java environment are unsuitable for constrained devices due to ROM footprint, RAM size, or processing power requirements. They cannot be adopted as such for embedded devices. Instead, one must either design a new API that allows best interoperability with native graphics support, or define a subset of an existing API.
Related JSRs in the J2ME arena include:
JSR-118 - MIDP2.0 - The LCDUI Graphics class under MIDP 2.0 is responsible for all the 2D graphics related features within the MIDP 2.0 Profile. However, there are some limitations in supporting advanced graphical features such as thick strokes, arbitrary shapes, affine transformation, etc. In addition, this API does not allow loading 2D vector graphics objects from external image files, such as SVG
.
JSR-135 - Mobile Media API - is a high-level control API for different media types, and it does not address the control of vector graphics formats and overlaying media. Compatibility with future extensions of JSR-135 will be discussed during the work, including possible control extensions to support vector graphics.
JSR-184 - Mobile 3D Graphics API - has been designed to efficiently render 3D scenes and animations. The API contains a high-level scene graph mode and low-level immediate mode in order to support several 3D applications. JSR-184 API has been optimized for rendering 3D data with polygonal meshes, and it does not address the 2D graphics rendering model with complex 2D paths, text, and animations.
JSR-209 - Advanced Graphics and User Interface - defines a subset of Java 2D, Swing, IMF (Input Method Framework), and Image I/O packages for CDC configuration. It is estimated that the memory required for supporting all these functionalities is too large to fit within the scope of CLDC and this will be dependent on AWT and not suitable for LCDUI of MIDP.
JSR-217 - Personal Basis Profile version 1.1 - intends to define limited wide line drawing support. The scope and requirements for the present JSR proposal are much wider (including more drawing primitives and SVG support). However, this JSR will be defined in a manner that will not conflict with the Personal Basis Profile.
Outside the J2ME arena, the following Java technologies are related:
Java 2D, defined for J2SE, satisfies the advanced 2D features covered in this proposal. However, Java2D does not satisfy the requirement for representing scalable images and animations. In addition, it is estimated that Java2D will not satisfy memory requirements of CLDC configuration, because it encompasses 2D shapes, text, and images in a single comprehensive model resulting in a large footprint size. Java2D has direct dependencies on AWT, making it unsuitable for LCDUI of MIDP.
There is an increasing demand for scalable 2D images that can adapt to devices with different terminal capabilities. Vector graphics is becoming the technology of choice for scalable image and animation representation on mobile devices. Vector graphics represents 2D content as geometric shapes: lines, rectangles, polygons, circles, smooth curves, and so on. In general, the advantages of vector graphics over raster graphics are:
TBD
No
None known or anticipated.
International text/font support is system dependent.
None known or anticipated.
Community Review Draft: Q3/2003
Public Review Draft: Q1/2004
Final specification: Q1-Q2/2004
E-mail, teleconference, and face-to-face discussions as needed and as appropriate
The RI and TCK will be delivered as a stand-alone optional package for the J2ME platform.
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 TCK we will charge a single one time fee of max $50 000 USD and annual maintenance fee, max $20 000/pa. TCK will include both binary environment and source code of the test suite. 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 additional single one time fee.
For RI in source code form we will charge one time access fee, and annual maintenance fee. Maintenance covers bug fixes, updates and new releases necessary due to spec changes, and when made generally available by specification lead. Binary license is free of charge.
Section 3: Contributions
In addition to the JSRs mentioned in Section 2.4, the following references may be applicable:
* SVG specification - < http://www.w3.org/TR/SVG11/>
* Mobile SVG Profiles - < http://www.w3.org/TR/SVGMobile/>
These items will be used for general reference purposes.
Section 4: Additional Information (Optional)