Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 256: Mobile Sensor API

Stage Access Start Finish
Maintenance Draft Review 4 Download page 27 Mar, 2009 27 Apr, 2009
Maintenance Release 2 Download page 22 Dec, 2008  
Maintenance Draft Review 3 Download page 17 Sep, 2008 20 Oct, 2008
Maintenance Release Download page 13 Jul, 2007  
Maintenance Draft Review 2 Download page 22 May, 2007 25 Jun, 2007
Maintenance Draft Review Download page 26 Feb, 2007 02 Apr, 2007
Final Release Download page 10 Apr, 2006  
Final Approval Ballot View results 28 Feb, 2006 13 Mar, 2006
Proposed Final Draft Download page 31 Jan, 2006  
Public Review Ballot View results 23 Aug, 2005 29 Aug, 2005
Public Review Download page 25 Jul, 2005 29 Aug, 2005
Early Draft Review Download page 22 Apr, 2005 22 May, 2005
Expert Group Formation   02 Nov, 2004 19 Apr, 2005
JSR Review Ballot View results 19 Oct, 2004 01 Nov, 2004
Status: Maintenance
JCP version in use: 2.6
Java Specification Participation Agreement version in use: 2.0

The API provides general Sensor API that extends the usability and choice of sensors for J2ME applications. It defines generic sensor functionality optimized for the resource-constrained devices like mobile devices.

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

Specification Leads
  Kimmo Loytana North Sixty-One Ltd
  Pia Niemela Nokia Corporation
Expert Group
  Cinterion Wireless Modules GmbH Esmertec AG LG Electronics Inc.
  Motorola Nokia Corporation North Sixty-One Ltd
  Samsung Electronics Corporation Siemens AG SK Telecom Co., Ltd.
  Sony Ericsson Mobile Communications AB SouJava Sun Microsystems, Inc.
  Tridium, Inc Vodafone Group Services Limited

Updates to the Original Java Specification Request (JSR)

The following information has been updated from the original JSR:


The Maintenance Lead from Nokia Corporation has changed to Adamu Haruna.

Maintenance Lead: Adamu Haruna

E-Mail Address:

Telephone Number: -

Fax Number: -


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.


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

Maintenance Lead: Kimmo Löytänä

E-Mail Address:

Telephone Number: -

Fax Number: -

Specification Lead: Pia Niemela

E-Mail Address:

Telephone Number: +358 50 480 2576

Fax Number: +358 71 807 0560

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Nokia Corporation

Name of Contact Person: Kimmo Loytana

E-Mail Address:

Telephone Number: +358 71 803 5252

Fax Number: +358 71 807 0530

Note that this information has been updated from this original JSR.

Specification Lead: Natalia Mulligan

E-Mail Address:

Telephone Number: +358 71 807 0568

Fax Number: +358 71 807 0560

Initial Expert Group Membership:

Supporting this JSR:

Nokia Corporation
Siemens AG
Sony Ericsson Mobile Communications

Section 2: Request

2.1 Please describe the proposed Specification:

This specification will define a generic sensor API for the J2ME applications, delivered and licensed as an optional package. The API will offer unified way of managing sensors, connected to the mobile devices, and easy access to the sensor data. The J2ME applications will be able to configure and control sensors transparently from underlying connectivity protocols, e.g. activate, deactivate sensor, launch sensor discovery, start data sampling, etc.

Emerging number of the sensor types, connected to the mobile devices using different communication protocols, and the lack of common approach in managing sensors make Mobile Sensor API very important. The J2ME application developers want to learn and utilize single way to manipulate the sensors.

The API is targeted to the resource-constrained devices such as mobile phones and needs to be memory-efficient to run on. On the other hand it must perform to cope with incoming sensor data.

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

JavaTM 2, Micro Edition.

The minimum requirement is the J2ME Connected, Limited Device Configuration v1.1.

This Optional Package should be usable with any J2ME Profile based on that Configuration as well as Profiles based on the Connected Device Configuration.

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 JSR is targeting to JavaTM 2, Micro Edition only. There is no relationship with the other Java platform editions.

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

No. Only the Executive Committee with responsibility for the J2ME specifications is required to vote on this JSR.

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

Currently there is neither common nor standard way of manipulating sensors for J2ME applications. This specification will define unified way to manage sensors and access sensor data. Generic functionality is included into the Mobile Sensor API to serve all sensor types. The application developers will be able to write applications easily without utilizing a number of non-standard and proprietary approaches for communicating with sensors.

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

There is no existing specification of the APIs that define basic sensor functionality for mobile devices.

Related J2ME JSRs:

    - General Connection Framework in MIDP2.0/CLDC1.1 provides low-level means to connect to any external device and to read data using created Connection. Enables application to connect to any device including sensor but does not make the communication transparent. It does not support any sensor specific connections.
    - Java APIs for Bluetooth (JSR 82) implements connectivity between bluetooth devices. This API enables applications to communicate with bluetooth capable sensors. However the API does not support sensor specific protocols on top of Bluetooth stack.
    - Location API for J2ME(JSR 179) sensor functionality is only confined to the location related applications. The specification does not allow to access actual sensor data.

Other related JSRs:

    - Java 3D API 1.3 includes Sensor API. It provides access to a variety of devices, such as six-degrees-of-freedom (6DOF) trackers and joysticks, means to register, process and reflect on screen data received from the sensors (events). Even though Java 3D API 1.3 (JSR 912) defines sensor in a general way, it is primarily designed in the context of the 3D graphics needs to serve only continuous-input devices such as six-degrees-of-freedom trackers and joysticks. Java 3D API is designed for J2SE and is very large by J2ME standards. The J2ME 3D Graphics API (JSR 184: Mobile 3D Graphics API for J2ME) does not include sensor definition and functionality.
    - No extensions or additions of sensor functionality are planned in Java 3D API 1.4 (JSR 189).

Comparing to existing J2ME JSRs that define sensors the suggested specification is a more general and extends the usability and choice of sensors for J2ME applications. At the same time it defines generic sensor functionality optimized for the resource-constrained devices like mobile devices.

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

The number of the sensors embedded or connected to the mobile devices emerging very rapidly. A sensor can comprise of many kind of devices from microphone and camera with pattern recognition to heart rate monitor and thermometer. Sensors and the data they provide may differ greatly from each other. The communication model and protocol are usually different for different sensors as well.

The application that wishes to utilize sensor data typically performs following operations with a sensor:
- Sensor detection (discovery).
- Sensor activation and calibration.
- Data capture (sampling initiation, data fetch, data processing (including e.g. filtering, calculations)).
- Sensor deactivation.

From the application point of view, receiving raw data from a sensor is an easy task. However, when it comes to gather data from many sensors at the same time and utilize it, it turns into a complicated, not straightforward job. Device resources, required to handle lots of signals from sensors can hurt the whole system performance seriously. Well-formed sensor API will resolve the situation. It will abstract the configuration procedure and the data format in a standardized manner and help to maintain the system performance.

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?


2.11 Are there any internationalization or localization issues?

No such issues which have an impact on the API.

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: Q1/2005
Public Draft Review: Q2/2005
Final Specification: Q4/2005

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

We expect to have a geographically distributed expert group, so e-mail is the primary communication method. Teleconferences and face-to-face meetings may be organized 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.

The Expert Group will provide status updates on the JSR Community Update Page on a monthly basis. These will include at least updates to the anticipated schedule, status of the specification and possible open issues where input is requested from the wider community.

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 and TCK will be delivered as stand-alone packages.

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).

There are no previous versions available.

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.

For the RI in source code form we will charge a one-time access fee, and an annual maintenance fee. Maintenance covers bug fixes, updates and new releases necessary due to specification changes, and when made generally available by the specification lead.

The binary license is free of charge.

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.

The Java 3D API 1.3 (JSR 912) (
Location API for J2ME (JSR 179) (
Java Sensor API (tinyvm.rcx.Sensor) of the Lego MindstormsTM RCX microcontroller (
Java Distributed Data Acquisition and Control API (JDDAC) (

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

Existing attempts to create Sensor API will be processed and analyzed to define generic sensor functionality optimized for J2ME applications.