 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
JSR ProposalTitle:Java Configuration Summary:The JSR models configuration in a generic way. It will support different formats/locations, and provide access in different ways. Hereby interoperability with future Java (Jigsaw) will be considered as feasible. Submitter:Credit Suisse Contact Name:Scot Baldry Contact E-Mail:scot.baldry@credit-suisse.com Contact Phone:+44 (20) 7883 2871 Contact Fax:- Spec Lead Name:Anatole Tresch Spec Lead E-Mail:anatole.tresch@credit-suisse.com Spec Lead Phone:+41 (44) 334 03 89 Spec Lead Fax:- Initial Group Membership:Anatole Tresch (Credit Suisse), Antonio Goncalves (individual), Werner Keil (individual), Otavio Goncalves de Santana (individual), Fabio Velloso (individual), Oliver B. Fischer (iJUG), Simon Martinelli (individual) Supporting this JSR:Credit Suisse, Redhat, Antonio Goncalves (individual), Werner Keil (individual), SouJava, iJUG (JUG Berlin Brandenburg), Simon Martinelli (individual), London Java Community (JUG), Adam Bien (individual), Joe Pullen (individual) Duration for this JSR:2 Section 2: Request2.1 Please describe the proposed Specification:The proposed specification will model configuration in a simple, generic and portable way. It will define an extendible and type-safe API for access, evaluation, injection and manipulation of configuration. The SPI will enable its use in different environments and will be powerful enough to support also advanced features such as multiple classloaders, environment contexts, multi-tenancy and staging. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Java SE 8. Interoperability with future Java versions, especially Jigsaw will also be considered as feasible. 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 is targeted at Java SE, but can be used in other platforms as well. Other specifications, from Java SE/EE, may wish to examine or contribute to this JSR, and eventually use the new model. Such changes are outside the purview of this JSR, but input from those groups will be welcomed. 2.4 What need of the Java community will be addressed by the proposed specification?Configuration is used in almost all types of systems to easily control well defined aspects of a system?s behaviour without having to change, rebuild and redeploy the system. Using a common configuration model increases interoperability of applications, modules, plugins significantly, since the configuration model allows to link the operational infrastructure with the functionalities deployed easily. Similarly developers get a common toolset and understanding that supports them to organize and store configuration for their applications effectively, thus helping them to better focus on the business logic to be implemented. Also modularization and third party integration can be improved since modules/plugins assembled can be easily configured in a unified way. 2.5 Why isn't this need met by existing specifications?Configuration is not modelled in the current platform. On SE the java.util.preferences API provides an API for system and user preferences, but its design and implementation flaws disqualifies it to be feasible as a base for an effective configuration solution. In EE there are multiple variants on configuration file formats and locations for deployment (these are not in scope by this JSR), but no mechanism is defined for providing application related configuration. 2.6 Please give a short description of the underlying technology or technologies:This JSR will be built based on Java SE 8, considering also interoperability with relevant features from Java 9 (Jigsaw) and Java EE. 2.7 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.config 2.8 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No. 2.9 Are there any security issues that cannot be addressed by the current security model?No. 2.10 Are there any internationalization or localization issues?No. 2.11 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No. 2.12 Please describe the anticipated schedule for the development of this specification.Early Draft Review: early 2015. 2.13 Please describe the anticipated working model for the Expert Group working on developing this specification.Communication will be conducted primarily through email and conference calls. Face-to-face meetings may be held if or when convenient. 2.14 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:The http://java.net/projects/javaconfig project site will be used to track all issues and disseminate information on the progress of the JSR. 2.15 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 be developed as standalone JSR. It will run on SE, but also provide flexibility for possible usage within alternate environments. RI and TCK will run based on Java SE 8. 2.16 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.17 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.The Spec is released under the Oracle Specification License; RI and TCK are licensed under Apache Licence version 2 (http://opensource.org/licenses/apache2.0.ph 2.18 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.Additional infos will be provided through http://java.net/projects/javaconfig a Wiki and a project?s users list (users@javaconfig.java.net). A publicly accessible expert discussion board for the JSR with interested stakeholders the JSR?s EG mailing list (experts@javaconfig.java.net) will be used. 2.19 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?Issues will be tracked at the projects JIRA at: http://java.net/jira/browse/JAVACONFIG 2.20 Please provide the location of the publicly accessible document archive you have created for the Expert Group.All relevant documents and communications will be available on the project site at http://java.net/projects/javaconfig Section 2.21:N/A Section 3: Contributions3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.There are different frameworks existing such as 3.2 Explanation of how these items might be used as a starting point for the work.The existing solutions or APIs give a good starting point for a uniform configuration model since they have a couple of similarities, such as different config locations (local and/or remote), different formats (xml, json, properties, ...), key/value pairs, overriding and combination features, non literal target type conversion, dynamic expression resolution and support for staging/environment dependent configuration. Section 4.1:Feedback from interested individuals and companies has been collected and some of the background work has already been started. |
