 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 295: Beans Binding
Reason: Withdrawn at the request of the Specification Lead. JCP version in use: 2.7 Java Specification Participation Agreement version in use: 2.0 Description: Provide an API that allows two properties of two beans to stay in sync. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Withdrawn The following information has been updated from the original proposal. 2009.02.05: Specification Lead: Peter Zhelezniakov E-Mail Address: peter.zhelezniakov Telephone Number: +7 812 336 4066 Fax Number: - 2007.02.22: Specification Lead: Shannon Hickey E-Mail Address: shannon.hickey Telephone Number: - Fax Number: - Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Sun Microsystems Name of Contact Person: Graham Hamilton E-Mail Address: graham.hamilton Telephone Number: +1 408 276 7102 Fax Number: +1 408 276 7700 Specification Lead: Scott Violet E-Mail Address: scott.violet Telephone Number: +1 408 276 7317 Fax Number: +1 408 276 7700 Initial Expert Group Membership: Oracle Supporting this JSR: Oracle Section 2: Request
2.1 Please describe the proposed Specification:Developers who write applications that compose Java Bean components often find themselves writing boilerplate that keeps pairs of properties in sync. PropertyChangeListeners are used to detect changes in the source and target properties and to convert and validate data as it moves between the source and target. For example, a Swing developer might write a half of page of code to keep the "text" property of a JTextField in sync with the "name" property of the selected Customer in a JTable. This specification will define an API that greatly simplifies connecting a pair of Java Beans properties to keep them in sync. The connection will be configurable: type conversion and validation operations may be applied before updating a property. For example, to connect a String property to a Date property, a String/Date converter would be used. Similarly, an application that wanted to constrain the legal values for the date property would use a validator. This API is intended to make connecting Java Bean properties simple. The Swing APIs embody an enormous collection of Java Beans and properties. In order for this JSR to be successful it must meet the needs of Swing's architecture and developers. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)desktop 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.This JSR targets Java Standard Edition. Should this JSR be voted on by both Executive Committees?No 2.5 What need of the Java community will be addressed by the proposed specification?This JSR will reduce amount of tedious and error prone code Java Beans developers must write, by making additions to the Java Beans API that uplevel connecting pairs of Java Beans properties. 2.6 Why isn't this need met by existing specifications?JSR 227 addresses the general data binding problem, and will provide a declarative solution. This JSR targets a relatively narrow special case of data binding with a programmatic solution. It could conceivably be used as part of a JSR227 implementation. Among other things, Expression Language (developed joinly by JSR-245 and JSR-252) provides the ability to lookup a property from a bean by name. A core part of this JSR is the ability to lookup properties from a bean. EL will considered as the API used to lookup properties for this JSR. 2.7 Please give a short description of the underlying technology or technologies:This specification will provide a means for synchronizing two properties of two objects. In addition the specification will enable conversion and validation of the data. For example, a converter could be used to format a Date into a String before the value is set on the target bean. In addition, the specification will enable a validation step to occur on data flowing from the target to the source. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.beans or possibly javax.beans.binding 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?No 2.11 Are there any internationalization or localization issues?No 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.13 Please describe the anticipated schedule for the development of this specification.The intention is to deliver this JSR as a component of Java SE 7 (code name "Dolphin"). Early Draft Review would occur in the second half of 2006, Public Review in the first half of 2007, and Proposed Final Draft in the second half of 2007. 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.It is anticipated that most work will be done by e-mail, with conference calls if needed. 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.An implementation of the spec will be developed on a public java.net project. As part of the java.net infrastructure a public web page will be regularaly updated with questions specific to the implementation. All questions and concerns raised by the community will be answered in a timely manner. As necessary, questions will be forwarded to the EG mailing lists. 2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.This JSR will initially be delivered standalone. However it is hoped that it will also be bundled into a future Java SE release. Any future revisions of this JSR will only be delivered as part of Java SE. 2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).Not applicable. 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.The RI for this JSR will be made available in binary form at no charge. The TCK for this JSR will be made available at no charge to Java SE TCK licensees. In addition, qualified individuals and not for profit organizations will receive access to the TCK at no charge. For other uses, the TCK will be available at $50K. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.Nothing available at this time. 3.2 Explanation of how these items might be used as a starting point for the work.Not applicable. |
||||||||||||||||||||||||||||||||||||||||||||||||||
