What does "withdrawn" status mean for a JSR?

Question

I was checking the JSR 227 page and see its status be shown as "withdrawn". What does this status mean? Does it mean it is deprecated? is there a newer version that has replaced this specification?

Answer 1

For you as a programmer, it doesn't mean anything.

Oracle invented a declarative way for the user interface of a JSF application to be connected to the underlying data services, and this is the core of their Application Development Framework (ADF). Since they have built it and are using it extensively in ADF, and since they are using ADF for their huge new ERP suite (Fusion Applications), it will stay around for a long, long time.

Oracle wanted to be able to say "standards-based" so they submitted their way as a JSR. IBM, who are using a different method, saw no benefit in granting their competitor an official JSR, so they blocked it.

The fact that it's been withdrawn is just housekeeping.

Answer 2

From the JCP Process document, section 2.1:

Upon request to the PMO any JSR proposal may be withdrawn by the submitter(s) without explanation prior to the completion of the JSR Approval Ballot.

So, it only means that it was withdrawn before approval, nothing more. Whether there's a replacement in the works or not is unclear. That particular specification simply shows that it was "withdrawn at the request of the Specification Lead" so you would need to contact John Smiljanic at Oracle to get the details.

It may be of some assistance reading the JSR Review Ballot comments, copied below for completeness. It may well be that the concerns raised by IBM and BEA convinced Oracle that it wasn't worth pursuing in its current form, but that's (I'd like to think informed) speculation on my part.

---

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 AG 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.

---