These are the final results of the Community Draft Ballot for JSR #68. The Executive Committee for ME has approved this ballot.
JSR68
StageCommunity Draft Ballot
Ballot durationJul 9, 2002 to Jul 15, 2002
Votes

ME

BEA Systems
Cisco Systems
Ericsson Inc.
IBM
Insignia Solutions
Matsushita Electric Industrial Co., Ltd.
Motorola
Nokia Corporation
PalmSource, Inc.
Philips Electronics UK Ltd
Research In Motion, LTD (RIM)
Siemens AG
Sony International (Europe) GmbH
Sun Microsystems, Inc.
Texas Instruments Inc.
Zucotto Wireless
Vote Log

ME

On 2002-07-15 Texas Instruments Inc. voted Yes with the following comment:
TI supports the view that the RI for Optional APIs must be made available separate from the underlying Profile or Configuration. This needs to be addressed prior to public review.
------------------------------------------------------------------------------
On 2002-07-15 Sony International (Europe) GmbH voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-07-15 Siemens AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-07-15 Zucotto Wireless voted No with the following comment:
We strongly support the concept of building blocks and encourage design reuse and any process that limits API fragmentation in the J2ME community. Rather than vote “YES, but…” we have voted NO to emphasize our concerns that must be addressed prior to final approval of JSR-68 including many ambiguities in the process. We echo those concerns expressed by others:

- “may” options for Building Blocks must be strictly limited (as JSR-68 has recommended for Profiles in Section 3) in sections 5.3.25 – 5.3.32
- Building Block process needs to be more open and inclusive with better or at least more explicitly defined communications with EC who are ultimately responsible for J2ME evolution
- Building Block approval process needs to be more rigorously defined and more open (see below)
- Agree with IBM’s licensing concerns (see below)
- Section 6.4.1 needs to be reworked


And add the following specifics:

BB Request Handling
-	Building block request approval decisions must not be made autonomously by a single EG spec lead or EG group particularly one with such limited membership as JSR-68. 
- There needs to be a dispute resolution process apart from the requesting spec lead/EG recreating the API themselves from scratch
	
BB Final Approval
-	JSR-68 process needs to be better defined  - for example is it your intention that every new BB will trigger a new Maintenance release of JSR-68 and therefore undergo Public Review and EC vote? 
-	This was implied in Tim’s email to the EC but is not stated in the JSR – the step should be made explicit between 5.3.9 and 5.3.10.
-	If this is the case, then the EC voting requirement is covered off 
-	a flow diagram of the entire process including all decision points would be helpful

Additional details are provided in an email to the EC and spec lead.
------------------------------------------------------------------------------
On 2002-07-15 PalmSource, Inc. voted Yes with the following comment:
- There is a concern over authority between this JSR and the JCP document that needs to be addressed.  Without more specific references to this JSR and its defined processes from with the overall JCP document, this JSR's processes may not be strictly enforceable since the JCP document is the first source of process details for the JCP.
- We echo the need for more openess and communication to the EC in regards to building block approval.  Community and public review ballots are not the appropriate place for EC feedback on building block definition and use.  
- 6.4.1 needs to be relaxed as it seems to stringent for optional packages.  Configurations are not even held to that degree of completeness within their RIs (e.g. CLDC RI).
------------------------------------------------------------------------------
On 2002-07-15 Research In Motion, LTD (RIM) voted Yes with the following comment:
In 5.3.16-5.3.32, the allowed set of changes should be kept conservative initially to prevent future problems.  Many of these requirements are part of the Java Language Spec "Binary Compatibility" chapter, perhaps by referring to the JLS, this section can be reduced in size and made more precise at the same time.
------------------------------------------------------------------------------
On 2002-07-15 Motorola voted Yes with the following comment:
We hope that the EG will make sure that the Building Block process is more open and inclusive of a broader set of input. We also would support stronger communication requirements with the EC.
------------------------------------------------------------------------------
On 2002-07-15 Insignia Solutions voted Yes with the following comment:
We share the concerns raised by IBM and Nokia regarding building blocks, and would like to see this issue discussed and resolved.
------------------------------------------------------------------------------
On 2002-07-15 Matsushita Electric Industrial Co., Ltd. voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-07-15 Ericsson Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-07-15 Nokia Corporation voted Yes with the following comment:
"
We support the general idea of building blocks, however we do share some of the concerns that IBM has raised about the process how BBs are created and accepted. We vote "yes" now, since we do not have a clear counter proposal to present at this point. We do however expect more discussion about this in the EC as well.

Regarding the issue of implementing multiple Profiles within one
Runtime Environemnt, we think that the current assumption of the
EG is right. Manufacturers should be able to choose the right
combination of specified Profiles and Optional Packages for their
products based on market requirements and decide the optimal way
to implement the platform without unnecessary restrictions when
interoperability of applications is not harmed.

For Optional Package RIs, we think that the rule 6.4.1 is wrong
and unacceptable. It defines that an Optional Package RI should
include a full Runtime Environment, which would require an Optional
Package RI to include an implementation of a Profile. This is not
acceptable. An Optional Package RI should only be required to provide
an implementation of the APIs defined in the Optional Package
specification and only provide a reference where suitable Profile
implementation can be obtained for making a complete Runtime
Environment. We assume that this is an editorial error, because the
rule is also in conflict with guideline 6.4.6, but nevertheless the
issue is important enough to bring up here."
------------------------------------------------------------------------------
On 2002-07-12 IBM voted No with the following comment:
IBM is voting no on this JSR because of concerns over the process to develop Building Blocks.  While, in general, we support the concept of Building Blocks, the process needs to be more open.  

As currently defined, the JSR 68 Specification Lead and Expert Group (J2ME-EG) have control over approving Building Block requests and the resulting specifications, without any input or approval from the Executive Committee (EC) or Java Community.  In the JCP, all other requests for new work are reviewed by the Java Community and the public; with approval by the EC.  This process bypasses the public, community, and EC, giving the J2ME-EG full authority over Building Blocks.  The only linkage to the EC is a weak suggestion that the Specification Lead report status to the EC (Section 5.3.11 "From time to time the J2ME-EG Specification Lead may provide reports to the J2ME Executive Committee on the status of the J2ME-EG."). 

The process needs to be more open to make sure that Building Blocks benefit from more diverse input and review.  A more open process would likely provide better specifications, less API fragmentation, and more opportunity for reuse. 

In addition, the JSR 68 Building Block process seems to be in conflict with the community review for JSR 171, JCP 2.5.  JSR 171 states that Building Blocks are proposed in an Umbrella JSR (UJSR) or as part of the JCP Maintenance Cycle.  Both of these approaches require public reviews and approval by the EC.  

IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.  IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage.  We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction.
------------------------------------------------------------------------------
On 2002-07-12 Philips Electronics UK Ltd voted Yes with no comment.
------------------------------------------------------------------------------
On 2002-07-11 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------