Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 184: Mobile 3D Graphics API for J2METM

Updates to the Original JSR

The following information has been updated from the original proposal.

2012.08.29: North Sixty-One has become the Co-Maintenance Lead.

Maintenance Lead: Erkki Rysä

E-Mail Address:

Telephone Number: -

Fax Number: -

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Nokia Corporation

Name of Contact Person: Kari Pulli

E-Mail Address:

Telephone Number: +358 7180 48975

Fax Number: +358 7180 52244

Specification Lead: Jyri Huopaniemi

E-Mail Address:

Telephone Number: +358 7180 37309

Fax Number: +358 7180 37133

Initial Expert Group Membership:

  • ARM
  • Motorola
  • Nokia Corporation
  • Siemens
  • Superscape
  • Vodafone Group PLC

Supporting this JSR:

  • ARM
  • Motorola
  • Nokia Corporation
  • Siemens
  • Superscape
  • Vodafone Group PLC

Section 2: Request

2.1 Please describe the proposed Specification:

This proposal specifies a lightweight, interactive 3D graphics API, which sits alongside J2ME and MIDP as an optional package.

The API shall be flexible enough for a wide range of applications, including games, animated messages, screen savers, custom user interfaces, product visualization, and so on. It shall not be limited to any particular type of application. It shall also be simple enough to use to make rapid development of compelling 3D applications feasible.

The API is targeted at CLDC class devices that typically have very little processing power and memory, and no hardware support for 3D graphics or floating point math. The API shall be defined such that implementations on that kind of hardware are feasible. However, the API shall also scale up to higher-end devices featuring a color display, a DSP, a floating point unit, or even specialized 3D graphics hardware. The API may therefore support features that are not strictly necessary on the very low-end platforms.

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

The target platform of this API is J2ME/CLDC. The API is proposed to be an optional package to be used together with several J2ME profiles, in particular MIDP.

Additionally, we should restrain the size such that the burden on the target platform for inclusion of the smallest conforming subset should be of the order of 100K of ROM/Flash space for a well-optimised implementation.

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

The specification brings support for 3D graphics to J2ME. Synthetically coded content, such as 3D graphics, has properties that enable attractive services and applications to be constructed that can overcome the limitations of the current mobile networks.

Interactive content on mobile devices includes games, navigation aids, messaging and custom user interfaces. All of these can be addressed using an interactive 3D API. The API shall be designed to supply interactive 3D rendering capabilities to applications in a way that is efficient in processor power required, in overall code size, and in working memory footprint. It shall provide these capabilities in a manner which makes content development natural and easy for MIDP developers.

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

Current proposals for integration of 3D into a Java environment are unsuitable for constrained devices due to ROM footprint, RAM size, or processor power requirements. They cannot be adopted as such for embedded devices. Instead, one must either design a new API for the embedded environment, or modify a subset of an existing API.

Specific ongoing JSRs in the J2ME arena which are related include:

  • JSR-134 - Gaming API is designed and optimised for gaming, targeting the CDC platform. While 3D is useful for games, it is not useful only for games and thus we view JSR-134 as complementary, not competing. By concentrating on interactive 3D graphics only, rather than on game-specific mechanisms, we hope to keep this JSR small, focussed, and independent of the feature set implemented in JSR-134.
  • JSR-135 - Mobile Media API is a high-level control API for different media types, and it does not address interactive 3D graphics. We feel that although high-level playback control of 3D content could be provided by JSR-135 in the future, that specification is not suitable for providing core 3D graphics functionality. Therefore, a separate JSR is needed.
Outside the J2ME arena, the following JSRs are related:
  • JSR-148 - 3D Media Utilities addresses volumetric imaging and 3D vector math. The volumetric imaging part of the JSR are not relevant to this JSR, because lightweight 3D content will be represented as polygonal data rather than volumetric data. The vector math package of JSR-148 should be used at least as a reference if similar functionality is to be defined within the proposed JSR. However, on the target platform the vector operations will in practice be mostly embedded within the implementation?s native code, for speed reasons.
  • JSR-912 - Java 3D is very large by J2ME standards. It is unclear whether even a ?cut down? version of JSR-912 would perform efficiently on the smallest platforms, given the design assumptions made for Java 3D.

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

Mobile devices may feature a great variety of graphical capabilities. Some of the target devices may only have a black & white display at 96x64 resolution, while others may feature a 320x240 display with 16-bit colors. In the future, even higher resolutions and color depths are expected. Similarly, processor speeds may range from tens to hundreds of MHz. The API should accommodate such differences, and be able to take full advantage of increasing capabilities and special hardware, such as 3D accelerators.

The main requirements for the API are:

  • Enable the use of 3D graphics on a variety of different applications
  • Do not assume the existence of relatively high-end hardware capabilities
  • Do not impose arbitrary limits on the size or complexity of 3D content
  • Support sophisticated features also on low-end platforms
  • Maintain low ROM and RAM footprint

To achieve sufficient generality without burdening the developer with drawing individual pixels, the API needs to be at least at the abstraction level of drawing static 3D objects on command. It is useful if the API would also take care of issues like building and maintaining a scene hierarchy, performing occlusion culling, animating the objects in the scene, and selecting the viewpoint, because a higher level of abstraction eases application development, decreases application size, and increases the amount of processing done in native code vs. Java code. The relatively lower level of abstraction has been proven successful by, for example, SGI's OpenGL and Microsoft's Direct3D, while high abstraction level APIs have been used in OpenInventor, Java3D, and several game engines (e.g., ID's Quake). Yet another successful approach has been a combination of a file format and a player, like VRML in 3D and Macromedia's Flash in 2D.

All 3D rendering is expected to be done in native code for speed and space reasons. Implementations may utilize hardware acceleration on platforms where it is available. Implementations written in Java are possible, but most likely not practical without using 3D hardware.

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


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

No, although the proposed implementation will be dependent on the specific profile implementations, such as MIDP, to transfer pixel arrays to the screen.

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

None known or anticipated.

2.9 Are there any internationalization or localization issues?

None known or anticipated.

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


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

The specification is expected to be finalized during Q4/2002.

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

It is up to the expert group to work out the details, but we are proposing to have 2-3 face-to-face meetings in the process and conference calls when needed. A kickoff meeting should be targeted hopefully for June before the summer holidays to get the work going.

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:

  • OpenGL -
  • VRML/X3D -
  • "Computer Graphics, Principles and Practice", Foley, Van Dam, Feiner and Hughes.

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

These references include a general description of available 3D standards, tools and techniques.