 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 341: Expression Language 3.0
JCP version in use: 2.9 Java Specification Participation Agreement version in use: 2.0 Description: This is an update to Expression Language 2.2, currently part of JSR 245, JavaServer Page (JSP) 2.2. Expert Group Transparency: Public Communications Issue Tracking Team
The following information has been updated since the original proposal.
2013.03.05: 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 Spec Lead and Expert Group have agreed to move to JCP 2.8.
2.19 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.
http://java.net/projects/el-spec/lists/jsr341-experts/archive (EG document archive) To receive emails directly, please sign up as a java.net member at https://java.net/people/new, then click the "Bookmark This Project" link on http://java.net/projects/el-spec to join the project as an Observer. Observers of the project can subscribe to the users@el-spec.java.net email list. This list is a reflector for the expert group email list (jsr341-experts@el-spec.java.net) and receives all emails that are sent to the experts list. It can also be used for community discussion related to the JSR. 2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?http://java.net/jira/browse/EL_SPEC 2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.Spec working documents are archived in the project wiki pages, accessible from http://java.net/projects/el-spec/pages/Home The frame maker spec documents can be found in the svn repository https://svn.java.net/svn/el-spec~source-code Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Oracle Corporation Name of Contact Person: Kin-man Chung E-Mail Address: kinman.chung Telephone Number: +1 408 276 7116 Fax Number: - Specification Lead: Kin-man Chung E-Mail Address: kinman.chung Telephone Number: +1 408 276 7116 Fax Number: - Initial Expert Group Membership: Oracle Corporation Supporting this JSR: Martin Marinschek Section 2: Request
2.1 Please describe the proposed Specification:The Expression Language (EL), has been part of JSP specification since JSP 2.0. It enables a JSP or JSF application to access and manipulate application objects or managed beans without Java codes. In Java EE 6, EL is an integrated component in CDI (Context and Dependency Injection for Java EE, JSR 299), and it allows direct use of CDI components in JSP or JSF. The Expert Group in JSP 2.0 realized that EL is useful on its own, and created a separate EL specification, independent of the JSP specification, even though they belonged to the same JSR. This proposed specification will place the EL specification in its own JSR. EL is highly configurable, and there are a lot of components that need to be configured or implemented before it can used. JSP or JSF containers usually handle such jobs as part of the container initialization. There is a need to make EL easier to use outside of a Java EE container. This is one important area this JSR would address. The proposed specification will also consider many other features that have been requested by the community. The following are some of the requests that have been collected. However, it is not the intention of this specification to turn EL into a general language and the original goal to keep it simple and easy to use will be followed. These requests, as well as any future requests, for language features and extensions will only be included after careful consideration by the specification experts. The EL context in the current EL API can be confusing. It may be a good idea to separate it into two contexts: parsing and evaluation contexts. EL define a set of type coercion rules. Sometimes the rules in specific cases are not what is expected or desired. It would be nice if the rules can be customized. Current EL functions are hard to use. It would be nice to be able to reference static methods in the EL expression, without having to define them in TLDs (Tag Library Descriptor), just like instance method invocations. Similarly, it would be nice to be able to reference static members and enum constants directly in EL expressions. Current EL functions are hard to use. It would be nice to be able to reference static methods in the EL expression, without having to define them in TLDs (Tag Library Descriptor), just like instance method invocations. Similarly, it would be nice to be able to reference static members and enum constants directly in EL expressions. Projection and Collection has been proposed and supported in other EL-like engines. They should be standardized. Date types should be properly supported, with appropriate comparison operators for them. Consider adding operators: equality, string concatenation, and sizeof etc. Some Cache control should be added to the spec, to allow user some control, and make implementation easier. It is one of the requirements in CDI that it be notified when expressions are evaluated, either before and/or after the evaluation. We need to explore the best way to achieve this. CDI EL names can have namespaces. An example is javax.enterprise.conversation. This may require new rules for parsing EL expressions. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Java EE and Java SE 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.Currently, Expression Language has only been used in Java EE platform. The proposed JSR will make it easy to use in Java SE as well. 2.4 Should this JSR be voted on by both Executive Committees?No. It should be voted on by the Java SE / EE Executive Committee only. 2.5 What need of the Java community will be addressed by the proposed specification?One of the main goals of the proposed specification is to address the requests from the Java community. The list of the requests are outlined in 2.1. 2.6 Why isn't this need met by existing specifications?JSR 245 JSP 2.1 was released in 2006, and there has been a couple of MRs to address minor issues in EL. Since the current EL is intended to be used in a JSP or JSF container, the current specification does not adequately address issues when used outside of these containers. A new MR would also not properly address the requested changes from the community. 2.7 Please give a short description of the underlying technology or technologies:See above. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)The EL API will continue to use the javax.el package name. 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 following dates are preliminary:
Mar 2011 Expert Group formed
Q3 2011 Early Draft
Q1 2012 Public Review
Q3 2012 Final Release
We intend to include Expression Language 3.0 as part of Java EE 7. The above dates may need to be adjusted as the schedule for Java EE 7 is more fully defined. 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.The primary means of communications will be emails, instant messaging and wikis. Conference calls and face to face meeting will be arranged if needed. 2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:* The public can read the names of the people on the Expert Group. Yes. This information will be available in the spec drafts and on the Update page of the JSR. * The Expert Group business is regularly reported on a publicly readable alias. We intend this to be the case. In addition, blogs will be used to keep the community updated on the progress of the JSR. * The schedule for the JSR is publicly available, it's current, and I update it regularly. The schedule will be available on the JSR Update page and will be kept current. * The public can read/write to a wiki for my JSR. It is unlikely that a public wiki will be provided, since public comunications will be happen either in a public forum or with a public mailing list. * I read and respond to posts on the discussion board for my JSR on jcp.org. Yes. * There is an issue-tracker for my JSR that the public can read. There will be. * I have spoken at conferences and events about my JSR recently. I have spoken at the JavaOne conference in September 2010 in a BOF session "Expression Language, community feed backs and future directions" * I am using open-source processes for the development of the RI and/or TCK. The RI for current EL is hosted at java.net, and is an open source project. It will remain so in the future. The TCK, however, is not open source. * The Update tab for my JSR has links to and information about all public communication mechanisms and sites for the development of my JSR. This will be the case. 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.Versions of the reference Implementations (RI) will be released regularly, as artifacts in a public maven repositories. Technology Compatibility Kit (TCK) will be available both stand-alone and as part of Java EE 7. 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.Note that this information has been updated from this original proposal. Specification license 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.Expression Language API: http://jcp.org/aboutJava/communityprocess/mrel/jsr245/index.html RI: Unified Expression Language project: http://uel.java.net 3.2 Explanation of how these items might be used as a starting point for the work.EL 2.2 and its reference implementation will be starting point for the work. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
