The Java Community Process(SM) Program - JSRs: Java Specification Requests

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy

JSR #256
Mobile Sensor API
JSR Review Ballot
Ballot duration: 2004-10-19 to: 2004-11-01

These are the final results of the JSR Review Ballot for JSR #256. The Executive Committee for ME has approved this ballot.

Votes

Ericsson AB

IBM

Insignia Solutions

Intel Corp.

Matsushita Electric Industrial Co., Ltd.

Motorola

Nokia Corporation

Philips Electronics UK Ltd

Research In Motion, LTD (RIM)

Siemens AG

Sony Ericsson Mobile Communications AB

Sony International (Europe) GmbH

Sun Microsystems, Inc.

Symbian Ltd

Texas Instruments Inc.

Vodafone Group Services Limited

Icon Legend
Yes
No
Abstain
Not voted

View Vote Log

On 2004-10-21 Insignia Solutions voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-10-22 Nokia Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-10-29 Intel Corp. voted Yes with the following comment:
We're confused about the relationship between JSR 256 Mobile Sensors and JSR 257 Contactless Communication.  Given the underlying "protocols" in 257 can be things like taking a picture of a bar code with a phone camera, we're not sure why 257 can't be handled as part of 256.  It doesn't appear that either API would pay a whole lot of attention to protocol details when abstracting API's for something like the bar code example.  But we think the intent of having two separate specs will be clearer when we get to the point of seeing drafts.  The use cases dealt with by both JSRs are important ones to cover in J2ME and so we support what these JSRs are trying to do.  As the groups begin developing drafts, whether there is overlap will become clearer and it can be handled then.  We think the two groups should ensure they share drafts early with one another so that they can coordinate if appropriate.  We'd also encourage both groups to make drafts available to the public (or at least on the JCP member page) as early as possible.<br /><br />  On another subject, we appreciate the submitters detailed response on TCK terms.  This is not a comment on their specific terms, but more that they fully answered the question in the JSR - we see some JSRs that provide only vague information about TCK terms.  With a required test suite that all implementers need to license from the same source, it is important to know about cost and any key conditions up front when the JSR is submitted.
------------------------------------------------------------------------------
On 2004-10-29 Siemens AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-10-29 Texas Instruments Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-10-30 IBM voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-10-31 Philips Electronics UK Ltd voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-10-31 Research In Motion, LTD (RIM) voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-11-01 Symbian Ltd voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-11-01 Matsushita Electric Industrial Co., Ltd. voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-11-01 Vodafone Group Services Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-11-01 Sun Microsystems, Inc. voted Yes with the following comment:
We agree with the need for work in the area outlined, and bringing access to RFID/NFC facilities into the API set (the proposed JSR 257). We are also somewhat concerned about the implications of different-yet-similar APIs between this JSR and the proposed JSR 257. We expect the spec leads to work to ensure that the API sets produced will, as well as meeting the functional goals, minimise duplication.

------------------------------------------------------------------------------