 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 291: Dynamic Component Support for JavaTM SE
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: Establish a JCP specification for a dynamic component framework supporting existing Java SE environments based on the OSGi dynamic component model specifications. Please direct comments on this JSR to the Spec Lead(s) Team
Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: IBM Name of Contact Person: Jim Colson E-Mail Address: jccolson Telephone Number: +1 512 823 7357 Fax Number: +1 512 838 4150 Specification Lead: Glyn Normington E-Mail Address: glyn_normington Telephone Number: +44 1962 815826 Fax Number: + 44 1962 842327 Initial Expert Group Membership: Apache Software Foundation Supporting this JSR: Apache Software Foundation Section 2: Request
2.1 Please describe the proposed Specification:This specification will define a dynamic component framework including component lifecycle for existing Java SE platforms. The dynamic component model will support assembly of applications from components and support implementation detail hiding between components as well as lifecycle management of those components. The specification will be built upon capabilities in existing Java SE platforms and provide a consistent and predictable dynamic component model across the family of Java platforms in conjunction with JSR 232 for Java ME (CDC). The specification will enable components to be declared through metadata and be assembled at runtime using a class loader delegation network. The specification will also allow components to be dynamically life cycle managed (install, start, stop, update, uninstall). 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)The specification will target all Java SE platforms: Java 1.2, 1.3, 1.4, and Java SE 5.0, 6.0. 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 will target Java SE. It will be in alignment with JSR 232 for Java ME. 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 need for a dynamic component model and lifecycle is well understood by several communities. These include the OSGi community, the Eclipse Community and the Apache Community who are all addressing this requirement in the same manner. This capability has already been brought into the Java community via JSR 232 for the Java ME (CDC) domain. This JSR will bring the same, compatible capability into the Java community for the Java SE domain. 2.6 Why isn't this need met by existing specifications?No current JSR (either complete or in process) defines a dynamic component and lifecycle solution to run on top of the existing family of Java SE platforms. However, JSR 232 does include this capability to run on top of Java ME (CDC based platforms) along with a comprehensive set of mobility services. JSR 277 has been filed to examine changes to the static module definition to be used within the Java SE platform for Java 7 (Dolphin) and beyond. JSR 277 is targeted for specification delivery in 2H/2007 with RI/TCK delivery as an integral part of Dolphin in 2008. This JSR aims to address the current needs for dynamic components based on existing Java SE platforms. When Dolphin becomes available, the specification lead of this JSR will either perform a maintenance release of this JSR or raise a follow on JSR to add Dolphin to the list of compatible supported platforms and to exploit Dolphin technology for static modules, as appropriate. 2.7 Please give a short description of the underlying technology or technologies:This specification will be based upon JSR 232 which references the recently published OSGi Service Platform Release 4 Core Specification. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)org.osgi.framework 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 targeted schedule for the JSR is as follows: - Expert Group formation: February 2006 - Early Draft Review: March 2006 - Public Review: May 2006 - Proposed Final Draft: June 2006 - Final Approval Ballot: July 2006 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.As typical, we anticipate a mixture of mailing list and occasional face-to-face or teleconference meetings to complete the specification. 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.The mailing list, or equivalent, used for Expert Group discussions will be readable by anyone who expresses an interest. The specification lead will maintain an interest alias for JCP members outside of the Expert Group. The specification lead will publish periodic milestone drafts and status to this list. The Expert Group may also use the list to request feedback on key issues facing the group. The specification lead will, on a quarterly basis, provide a brief JSR status to the JCP PMO, for publication to the Java community. This will include the current schedule for the JSR and notes on any major events that have occurred in the previous quarter. 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.The RI and TCK will be delivered stand-alone. 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).N/A 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.IBM will license the specification to all interested parties. The TCK and RI will be licensed separately. The RI will be delivered at a cost not to exceed US$50,000 for a three-year license. There could be a separate charge for maintenance. The TCK will be delivered at a cost not to exceed US$50,000 for a three-year license. There could be a separate charge for maintenance. 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.JSR 232 will be used as a basis for this JSR. In particular, this JSR will reference the OSGi Service Platform Release 4 Core Specification which is part of the JSR 232 specification. http://jcp.org/en/jsr/detail?id=232 http://jcp.org/aboutJava/communityprocess/edr/jsr232/index.html http://www.osgi.org/osgi_technology/download_specs.asp?section=2#Release4 3.2 Explanation of how these items might be used as a starting point for the work.The OSGi Service Platform Release 4 Core Specification, as referenced in JSR 232, contains specifications of modularity and lifecycle capabilities which will be used as the basis of the dynamic component system. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.None. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
