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 #227
A Standard Data Binding & Data Access Facility for J2EE^TM
JSR Review Ballot
Ballot duration: 2003-06-24 to: 2003-07-07
These are the final results of the JSR Review Ballot for JSR #227. The Executive Committee for SE/EE has approved this ballot.
Votes

SE/EE
Apache Software Foundation
Apple Computer, Inc.
BEA Systems
Borland Software Corporation
Caldera Systems
Cisco Systems
Fujitsu Limited
Hewlett-Packard
IBM
Lea, Doug
Macromedia, Inc.
Nokia Networks
Oracle
Progress Software
SAP SE
Sun Microsystems, Inc.
Icon Legend
Yes
No
Abstain
Not voted
View Vote Log

SE/EE
On 2003-06-25 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-06-30 Oracle voted Yes with the following comment:
Oracle understands IBM's issues, but believes there might be a misunderstanding as to the details of this JSR.  The scope of this JSR is actually fairly small and limited to the interfaces and formats required to be able to take any binding and have it be portable to any standard server.  The minimum requirement for this functionality is the Declarative Binding and Data Control.  They each exist for each other.  The scope of this JSR will only cover the interfaces to these objects and not specific implementations.  That would be vendor-specific.  Oracle would be happy to clarify any unclear points in this proposal as we have with many of the other EC members.
------------------------------------------------------------------------------
On 2003-06-27 Cisco Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-06-30 IBM voted No with the following comment:
This JSR contains some interesting ideas.  However, we are concerned about the breadth of scope and the lack of clarity regarding important aspects of this JSR.  In particular, we think this JSR is too broad in scope, including elements of business services, data access, and user interface bindings.  The proposed specification would combine these aspects, creating undesirable coupling between the design of data controls for business services and the needs of user interface presentation.  This work should be divided into two separate activities, one to define business services and data controls for these services, and one to define declarative user interface bindings.  This would result in improved focus and would lead to specifications that better address the needs of these distinct areas.  In addition to this major issue, we have concerns over the lack of detail about the data controls proposed by this JSR, certain aspects of the declarative bindings, and the relationship to JSRs 114 and 127.  We are sending an email to the SE/EE EC detailing these concerns.  

------------------------------------------------------------------------------
On 2003-06-30 BEA Systems voted No with the following comment:
BEA also has significant concerns about the scope and factoring of JSR 227 and is thus voting "No". Specifically, we believe the functionality embodied in Data Controls should be in a separate JSR from the Declarative Bindings specification because Data Controls would be generally usable outside the stated data binding use cases. Thus, coupling these concepts together in a JSR is not desirable. Also, as the proposed Data Controls architecture is a normalization layer for a variety of data source types and service types, we believe this is a sufficiently complex topic that warrants an independent JSR.
------------------------------------------------------------------------------
On 2003-07-02 Apple Computer, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-07-02 Lea, Doug voted Yes with the following comment:
I'm confident the concerns expressed by IBM and BEA
can be addressed in an expert group.
------------------------------------------------------------------------------
On 2003-07-03 SAP SE voted Yes with the following comment:
SAP believes that this JSR has good potential to simplify the development of Java-based business applications by binding separate Java technologies together and establishing common design patterns that yield productivity gains. The concept of Declarative Bindings will further reduce the programming effort, making it easier for application developers to focus on solving business problems rather than systems-level details. Nevertheless, we believe that this JSR needs to be further scoped out by the Expert Group as soon as it is formed. Problems, such as like normalizing the transactional behavior of different data sources, or defining concrete metadata for complex Business Services, should be discussed in separate JSRs in order to maintain focus. Furthermore, selecting meaningful use cases for Declarative Bindings will require significant coordination with other JSRs, and the Spec Lead must ensure the architectural integrity of the J2EE platform. Due to its broad impact to the platform, transparency of the overall development effort is essential. Nevertheless, SAP believes that this JSR presents good opportunities for the Java community, as well as room for innovation in other JSRs and therefore votes 'YES' for this JSR.
------------------------------------------------------------------------------
On 2003-07-06 Nokia Networks voted Yes with the following comment:
Based on the information available on the JSR proposal, issues raised by IBM and BEA and clarifications given by Oracle, this JSR should proceed. As fars as scoping is concerned, it should take place as first task of the EG. Additionally, it is quite understandable that the JSR proposal as such cannot give the level of details that some of the concerns in discussion on topic have been addressing. Therefore, the concerns expressed by IBM and BEA should be addressed in EG at early phase of the JSR, after scoping. In addition, it is not desirable that significant technical decisions within JSR are expected to be made already prior involvement of the EG. Thus, detailed technical designs shouldn't be carved into stone until EG discusses and approves them.
------------------------------------------------------------------------------
On 2003-07-07 Caldera Systems voted Abstain with the following comment:
We share SAP's concerns about the effect of this
JSR on the architectural integrity of J2EE, and
are unsure whether the EG can be successful in
following all the (somewhat conflicting) directives it's being given on this JSR.

------------------------------------------------------------------------------
On 2003-07-07 Macromedia, Inc. voted Yes with the following comment:
Considering the value of this technology to the mainstream web developer and the dangers of tackling it with sloth, we must summon optimism that the JCP Executive Committee and the JSR Expert Group can refine the scope of this JSR going forward, and enthusiastically wish to shift the debates about control and contractual specifics into the expert group without the delay a NO vote would cause.
------------------------------------------------------------------------------
On 2003-07-07 Progress Software voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-07-07 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-07-07 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-07-07 Borland Software Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-07-07 Apache Software Foundation voted Yes with no comment.
------------------------------------------------------------------------------