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 #258
Mobile User Interface Customization API
JSR Review Ballot
Ballot duration: 2004-11-02 to: 2004-11-15
These are the final results of the JSR Review Ballot for JSR #258. 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-11-12 Intel Corp. voted Yes with the following comment:
While there doesn't appear to be overlap between the JSR 258 proposal and the JSR 209 Early Draft, the JSR 258 Spec Lead should coordinate with the JSR 209 Spec Lead to ensure there is no unnecessary duplication and especially that solutions do not unnecessarily deviate from J2SE.
------------------------------------------------------------------------------
On 2004-11-15 Ericsson AB voted Abstain with the following comment:
Ericsson Mobile Platforms supports the intention behind JSR-258 proposal. When we had reviewed the JSR-258 proposal, we found no overlap of functionality mostly because pluggable look and feel was not part of JSR-209. The interesting feature of JSR-258 was that it proposed to be independent of the underlying UI Toolkit and addressed CLDC as well. There has been lots of discussions on the ME Executive Committee mailing list since then and we have been exposed to new information that we were not aware of when we had supported this JSR. We have come to know that the discussion on pluggable look and feel is still on-going in the JSR-209 EG and that there has been liaison from OMTP to JSR-209 EG for UI customization. We abstain from this voting since we would like to see this discussion be concluded in JSR-209. We feel that in the best interest of the community this discussion needs to happen before this JSR is started.
------------------------------------------------------------------------------
On 2004-11-04 Nokia Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-11-12 Siemens AG voted Yes with the following comment:
Siemens assumes that the JSR 258 and JSR 209 specification will not overlap, in the area of CDC, with relevant customization aspects considered by JSR 209.
------------------------------------------------------------------------------
On 2004-11-12 Motorola voted No with the following comment:
Motorola does not see a need for JSR 258.  We believe that it is confusing to the community to open up another customization JSR when JSR 209 is already considering these aspects. Additionally, we are not convinced that there is even a need for a standardized programmatic control of deep customization. If there is a need we feel it will be better addressed by XML which can be standardized outside of the JCP.

------------------------------------------------------------------------------
On 2004-11-12 Vodafone Group Services Limited voted No with the following comment:
JSR 258 is an attempt by Nokia to take control of the UI customisation
UI customisation is in scope of JSR 209. We beleive Nokia's 258 is really an attempt to limit UI customisability rather than to provide it.

JSR 258 is not needed
JSR 209 is already working on UI customisation issues PLaF for deep customisation, and SYNTH (XML) for theming/skinning. SYNTH is available in Swing for J2SE, so there is no reason why 209 should not consider it for the CDC
Deep customisation of native UI widgets can be achieved using XML, which can be standardised outside of the JCP (W3C, OMA, or OSGi)
We have to question whether another body other that the JCP should address some of these issues detailed within 258.

Operators don't want 258
Vodafone is a large operator. We don't want it and have not heard of any other operator who want it. OMTP is liaising with JSR 209 regardng UI customization ans theming/skinning. JSR 209 is where the operator interest, in the subject of UI customisation is directed

More detail
The OMTPconsortium has opened a dialog this year to communicate requirements to JSR 209 regarding these issues and Nokia is participating in both OMTP and JSR 209.
If PLaF is removed from JSR 209 and replaced with functionality coming from JSR 258 then manufacturers will face extra licensing costs.
In order to provide the same level of customisation as is available via SWING PLaF, JSR 258 will cause the same implementation burden which has been addressed as one of the reasons to be removed from the JSR 209.
SWING PLaF provides a very good level of UI customisability grater than what is currently available with native terminal UI toolkit (including EPOC. It is impractical to attempt to equal the same depth of customisability using XML.
Some native UI implementations could require shutdown and restart in order to affect UI customisation, So it is only practical to provide this type of customisation by way of a configuration file (XML) rather than by java.


------------------------------------------------------------------------------
On 2004-11-12 IBM voted Yes with no comment.
------------------------------------------------------------------------------
On 2004-11-12 Sun Microsystems, Inc. voted No with the following comment:
Sun believes that it is important for the community to step back
and get clarity on the relationship of this proposed JSR-258 to
JSR-209, given their apparent overlap of scope.

The JSR-209 EG is already in the process of discussing UI skinning
requirements with the community, and this work should not be
preempted by another JSR. Additionally, the JSR-209 EG has been
aware (and more so now) of the need for an architecturally neutral
UI skinning solution. We should be careful to not introduce 
fragmentation into J2ME with overlapping JSRs addressing similar
requirements.

Finally, it appears that JSR-258 has not been adequately socialized
with the participants in JSR-209, -216, -217 and other related EGs.
We are voting "no" in the hopes that Nokia will better align their
proposal with existing J2ME activities.

------------------------------------------------------------------------------
On 2004-11-15 Research In Motion, LTD (RIM) voted Abstain with the following comment:
We would strongly suggest that the potential overlap issue between JSR209 and JSR258 be resolved before JSR258 to initiate.

------------------------------------------------------------------------------
On 2004-11-15 Sony Ericsson Mobile Communications AB voted Yes with the following comment:
Sony Ericsson belives there is a need for JSR-258. We think that this JSR will not overlap with JSR-209 but we think that there is a need to coordinate with JSR-209 to make sure no overlap is created. JSR-209 has only planned to address the CDC space and it has not been clear in the charter of JSR-209 that this issue belongs to the JSR-209 domain.

We also believe that it is vital for this JSR to listen to the needs of the operators in this area and it will be important to listen to requirements from OMTP and other operator forums.

If the progress in this expert group      indicates that the problems are not solved, we think that it would be OK to start another JSR in the same functinal space with a different setup.

We also think that it will be very hard to get a working and broad agreement on how to do a comming customization format and model. If this goal is not met, the JSR should not go to final with a washed out proposal that does not create a good level of commonalities. Still, in the spirit of innovation - we like to see what can be done and we would cooperato to create a good specification. Therefore we vote "yes" to this JSR review balot.




------------------------------------------------------------------------------
On 2004-11-15 Texas Instruments Inc. voted Yes with the following comment:
TI believes that well-formed JSRs that unify the J2ME API space are most important for the health of the J2ME developers community. JSR-258 offers hope of this.
------------------------------------------------------------------------------
On 2004-11-15 Symbian Ltd voted Abstain with no comment.
------------------------------------------------------------------------------
On 2004-11-15 Philips Electronics UK Ltd voted No with the following comment:
While we support the principle of this JSR, we are unable to support it in its current form due to the apparent extensive overlap with discussions already in progress within the JSR-209 EG and in progress between the JSR-209 EG and an external organisation. We believe more time and consultation is needed to define a rational relationship between -209 and this JSR or any successor.

We support the principles that any UI customisation API defined by JCP must be independent of the UI toolkit concerned and must not be specific to swing (or indeed UI toolkits written in Java) or specific to CDC. It seems to us that these principles may be easier to achieve in a stand-alone JSR (which is able to define new APIs) than in JSR-209 however we do not have enough visibility of the discussions in -209 to have formed a real conclusion. More information & discussion is needed here.
------------------------------------------------------------------------------
On 2004-11-15 Insignia Solutions voted Abstain with the following comment:
There are many operators that desire a method to deeply brand the subscriber experience. A method to seamlessly and securely execute this functionality OTA will be essential.

Frankly, this adds yet another reason to deploy sophisticated device management platforms, so it is in Insignia's best interests to see the technology come to market, one way or the other.

However, the political elements of 209 and 258 are clear, too clear perhaps. My primary concern is the impact of control and licensing fees on this important aspect of the platform.

Therefore a resolution on how this will be addressed should be concluded before another JSR in this area is started.   
------------------------------------------------------------------------------
On 2004-11-15 Matsushita Electric Industrial Co., Ltd. voted No with the following comment:
We strongly recommend that the potential overlap issue between JSR209 and 258 be resolved before starting JSR258.
------------------------------------------------------------------------------