 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 256: Mobile Sensor API
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: 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) Team
Updates to the Original Java Specification Request (JSR) The following information has been updated from the original JSR: 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.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: jsr256 Telephone Number: - Fax Number: -
Specification Lead: Pia Niemela E-Mail Address: pia.s.niemela 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: kimmo.loytana 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: natalia.mulligan Telephone Number: +358 71 807 0568 Fax Number: +358 71 807 0560 Initial Expert Group Membership:
Supporting this JSR: Nokia Corporation 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:
- 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:
- 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: 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.)javax.microedition.sensor 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?No 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?No 2.13 Please describe the anticipated schedule for the development of this specification.Early Draft Review: Q1/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) ( http://java.sun.com/products/java-media/3D/) 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
