 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 273: Design-Time API for JavaBeansTM JBDT
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: This JSR extends the JavaBeans specification and APIs to improve design-time functionality for component authors to leverage within the visual design environments in IDEs. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Withdrawn
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Sun Microsystems, Inc. Name of Contact Person: Joe Nuxoll E-Mail Address: joe.nuxoll@sun.com Telephone Number: +1 650 786 0831 Fax Number: +1 650 786 9551 Specification Lead: Joe Nuxoll E-Mail Address: joe.nuxoll@sun.com Telephone Number: +1 650 786 0831 Fax Number: +1 650 786 9551 Initial Expert Group Membership: BEA Systems, Inc Supporting this JSR: BEA Systems, Inc. Section 2: Request
2.1 Please describe the proposed Specification:This JSR extends the JavaBeans specification and APIs to improve design-time functionality for use within IDEs. Some key changes that are proposed are:
* Standardize common "extensions" to JavaBeans prevalent in current IDEs * Clean up and specify common meta-data used by many tool/component vendors in BeanInfo * Clarify expected behavior of IDEs with respect to PropertyEditors, Customizers, etc. * Possible: Investigate a JSP tag library design-time rendering scheme for IDEs It was a key goal of this JSR to be incorporated into version 6.0 of the J2SE platform (Mustang), but this technology will likely have to be released standalone after Mustang. It hopefully will be rolled into the next release of the J2SE platform. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2SE 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.J2SE is the primary delivery platform, though this technology will be applicable to all of the platforms. JavaBeans is a technology designed to make the design-time experience of all technologies more tool-friendly. 2.4 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?The design-time experience for component users will be greatly enhanced. Component authors will be able to better leverage the IDE environements where their components will be used in building applications. This API will allow them rich interaction with the host IDE by leveraging the JSR-198 API in conjuction with the additions to the JavaBeans APIs. 2.6 Why isn't this need met by existing specifications?The existing JavaBeans specification falls short of the design-time API of competing software platforms in several areas. Each of the major Java IDE vendors have addressed these shortfalls with proprietary APIs for design-time functionality. This JSR is a move to standardize the common extensions to JavaBeans and raise the bar for design-time capabilities for component authors in all Java IDEs. 2.7 Please give a short description of the underlying technology or technologies:The Design-Time API for JavaBeans will expand on the current JavaBeans API, which includes several interfaces and classes. Some of the new interfaces will be designed for IDE vendors to implement, and several will be for component vendors to implement and deliver with their components. Where applicable to the IDE vendor, this JSR will build upon the work done in JSR-198. This includes utilizing JSR-198 classes that exist, and extending the JSR-198 concepts where they currently don't exist. The intent of this synergy is to give the tools developer a single API and documentation to work with when adding to and extending standards-compliant tools. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.beans.* for JavaBeans extension classes and interfaces javax.ide.* for IDE-implemented classes and interfaces 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?None 2.10 Are there any security issues that cannot be addressed by the current security model?None 2.11 Are there any internationalization or localization issues?None, though some guidelines on making design-time classes localized will be included in the spec. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?JavaBeans 1.01 will be updated and extended by this work. The JavaBeans spec itself may be updated post Mustang to reflect the extensions provided by this JSR. 2.13 Please describe the anticipated schedule for the development of this specification.(tentative) 9-12 months, dates/timeline to be determined by the initial expert group 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.This group will be run primarily with email discussion with occasional conference calls and other distributed team technology uses. We will also likely have a few face-to-face meetings in the Bay Area. 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.It will be up to the expert group to best determine the working model for the group, thus we have not yet defined how we will work. It has been suggested that we leverage the collaborative tools provided by the Java.Net infrastructure, which we will look into. 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 J2SE release. Any future revisions of this JSR will only be delivered as part of J2SE. 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 J2SE TCK licensees. In addition, qualified individuals and not for profit organizations will receive access to the TCK at no charge. 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.JavaBeans 1.01 Specification: Sun Java Studio Creator Design-Time API: http://developers.sun.com/prodtech/javatools/jscreator/reference/apis/index.html JSR-198 (Java IDE extensions API): http://www.jcp.org/en/jsr/detail?id=198 3.2 Explanation of how these items might be used as a starting point for the work.The Design-Time API for JavaBeans will build on and extend the JavaBeans 1.01 specification. The Creator Design-Time API was designed (over the last 2 years) as a prototype of a general Design-Time API for JavaBeans. This API will be the starting point for the JSR API, but is expected to diverge heavily from the Creator version. The JSR-198 APIs will be used where a potential overlap exists between this API and those in JSR-198. The expert group will determine when and where this condition applies. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.None |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
