Status: MaintenanceJCP version in use: 2.7Java Specification Participation Agreement version in use: 2.0

Description:
This JSR is an update to the 1.2 version of the JavaServer Faces specification. This is the first major revision of the JavaServer Faces specification since JSR 127.

Please direct comments on this JSR to the Spec Lead(s)

Team

Specification Leads

Ed Burns

Oracle

Roger Kitain

Oracle

Expert Group

Apache Software Foundation

Baxter III, Lincoln

BEA Systems

CA Technologies

Ericsson AB

Exadel, Inc.

Fallows, John R

Fujitsu Limited

Geary, David

Hightower, Richard

IBM

ICEsoft Technologies Inc.

ILOG

Infragistics, Inc

Jacobi, Jonas

LEE, Jason

Liferay, Inc

Mann, Kito D.

Mettu, Kumara Swamy

Oracle

Ottinger, Joseph

Prasanna, Dhanji R.

Red Hat

SAP Labs

SAP SE

Senger, Vinicius

Shabalov, Igor

Slominski, Bernhard

Sun Microsystems, Inc.

Truchsess, Norbert

VMware

If you would like to be added to the observer alias for this JSR and receive e-mail updates on the progress of the JSR, please send e-mail to the Spec Lead with "Add to observer alias" in the subject line.

2.1 Please describe the proposed Specification:

This JSR will bring the best ideas in web application development (circa early 2007) to the Java EE platform. The Expert Group will be harvesting existing ideas that:

Maximize the productivity of the web application development experience, for graphical IDE and command-line developers.

Minimize the complexity of maintenance of the web application during its production lifetime.

Make it easy to create responsive user interfaces through effective use of Ajax techniques. This includes enabling applications that have nearly all of the MVC controller UI logic and intra-page component interaction into the client, while keeping a sensible level of application logic on the server. Ideas that allow for graceful degredation when JavaScript is diabled or unavailable are also important.

Make it possible to expand the reach of your web application by continuing to support fully functional server based web applications that do not use JavaScript in the client.

Leverage modularity to expand integration opportunities between the JSF framework and other client and server side web application technologies. This would make it easier for a developer to use individual parts of JSF without being forced to use all of it. For example, the request processing lifecycle is useful even without the JSF View being present. As another example, JSF has a robust I18N and L10N capability. It should be possible to use this capability without using JSF components for your UI. A short way to characterize this is, "be mashup friendly".

Make it easy to expose your data by leveraging the Java Persistence API

Requirements are grouped into four major categories: Ease of Development, New Features and Fixes, Performance, Technology Adoption. Following are some initial requirements that will be prioritized and considered when the Expert Group convenes. Not all of these ideas will be in the final specification. Some of these requirements may be met in the Servlet specification (or other Java EE specification) but they are stated here because they are critical to the success of JavaServer Faces.

Ease of Development

While this was the major theme for Java EE 5, it was not the major theme for the version of the JavaServer Faces specification included therein. The act of writing JSF applications and components "by hand" will be made much easier by this JSR. Example requirements in this category include:

Component aggregation. Allow development of custom component with little or no Java coding. [A] Perhaps consider a standard set of aggregations.

Allow for "zero configuration" web applications. No faces-config.xml, no web.xml. If necessary, annotations will be used to supplement the configuration data.

Vastly improve the developer experience with regard to error messages that happen during iterative development, and even during deployment of the application. For example the EG will consider options including, allowing the developer to tell the runtime what stage of development the web application is in, and take action accordingly: Development, Test, Deployment. Line precise error reporting. Pluggable Exception Handling.

Provide default exception handling mechanisms. For example, all runtime errors get forwarded to an error page.

Eliminate the need to author a JSP tag handler when writing JSF components.

Declarative Renderers, otherwise known as Renderers without resorting to out.println().

Real world, production view description technology, including templating: include something influenced by Facelets, JSFTemplating or Tiles in the specification.

Make it very easy to create CRUD based applications.

There are also a number of container improvements that should be considered to improve developing web applications in general:

Eliminate the "deployment step". All the artifacts that comprise a JSF application can be modified while the application is running. This will bring the responsiveness people have been used to with iterative JSP development to the JSF developer. One design idea for this is to allow JSF artifacts to be authored in Script.

Expand the contract of the exploded WAR (and non-exploded WAR) to have knowledge of JSF artifacts. For example, define a place within the WAR structure for such artifacts as components, renderers, converters, etc. Having a concrete correspondence between the constituent parts of a JSF application and actual directories within a WAR will make it easier to understand an application and also map help with the elimination of the deployment step.

New Features

Requirements in this category stem from feedback from real world JSF users and are incremental improvements on the existing specification. This category includes fixes and updates to existing APIs. Example requirements in this category include:

Expand the request processing lifecycle to be aware of Ajax. This may include describing a small developer-contract footprint JavaScript library as part of the JavaServer Faces specification.

Separate the "build the tree" and "render the tree" processes into two separate lifecycle phases.

Allow for partial tree traversel during lifecycle execution via Ajax.

Allow for bookmarkable JSF pages. More broadly, if HTTP GET can be used, it should be used.

The flexibility of the JavaServer framework can lead to performance concerns. Requirements in this category make modifications and restrictions to the specification to increase performance across the board for all implementations of the specification. Example requirements in this category include:

Saving and restoring page deltas rather than saving and restoring the full view state each time.

Re-do UIComponent state saving with a view towards making stateless components the default.

Allow for moving as much of the event processing and inter-page component interaction into the client as possible. This may imply specifying client side controller framework.

Streamline the rendering process via caching if possible.

Improve the interceptor mechanism delivered via the PhaseListener feature so that the developer can control exactly what kinds of requests are allowed to be processed by each PhaseListener instance.

Adoption

Increasing the capability of the JavaServer Faces standard will continue to attract more people to write applications targeting the standard, thereby raising the bar for Java web applications. Features in this category aim to attract new developers to use products that implement the JavaServer Faces specification. Example requirements in this category include:

Enable components to have a client based lifecycle in addition to, or instead of the server based request/response lifecycle. Such a client based lifecycle would enable use-cases such as drag-and-drop, master-detail and sub-dialogs on a single page interface web application.

Improve the UIComponent specification to allow an increase in the interoperability of UIComponent libraries from arbitrary vendors.

Enable applications to use features that are defined in the JavaServer Faces specification but are intended for use in the Java EE platform as a whole. For example, the managed bean facility is useful even in an application that only uses Servlets from Java EE but provides the rest of the web application features from software outside of the platform.

Allow JSF application resources to be accessed via REST.

Enable components that publish events via RSS/Atom.

Add support for REST (JSR 311)

Broad and pervasive support for scripting at all levels of the specification. It will be possible to use a scripting language to write all executable artifacts in a JSF application.

Specify command line interface for authoring JSF applications.

Support for passing values from page to page. This will be a standardization of the many different Dialog/Conversation/Scope/Flash ideas currently in use.

"Skinning", or "Themeing" of components.

An important target user for JavaServer Faces technology is the developer who relies on an Internet Service Provider (ISPv) to host their application, as well as hosting their development environment. It must be easy to iteratively develop a JavaServer Faces application that is hosted entirely on an ISP.

#
Make it easy to create responsive user interfaces through effective use of Ajax techniques. This includes enabling applications that have nearly all of the MVC controller UI logic and intra-page component interaction into the client, while keeping a sensible level of application logic on the server. Ideas that allow for graceful degredation when JavaScript is diabled or unavailable are also important.

Make it possible to expand the reach of your web application by continuing to support fully functional server based web applications that do not use JavaScript in the client.

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 specification targets the Java EE 6 Platform. It will be based on the corresponding release of the Java SE platform.

2.4 Should this JSR be voted on by both Executive Committees?

No. Just the SE/EE Executive Committee.

2.5 What need of the Java community will be addressed by the proposed specification?

While JavaServer Faces has succeeded in becoming the standard way to build web application user interfaces while ensuring maximum container portability and minimizing vendor lock-in, the state of the art of web application user interface development has advanced significantly since the first major draft of the specification. The Java community finds itself in a similar situation to that in which the first version of the JavaServer Faces specification was initiated: Many great ideas but no standard specification that delivers them to developers and the marketplace. In fact, many of these great ideas are built on top of the JavaServer Faces Specification but, are not, themselves, standards. It is time to harvest these ideas and bring them to a wider audience in manner consistent with the rest of the Java Platform.

2.6 Why isn't this need met by existing specifications?

The problem domain of web application user interface and lifecycle development is not covered by any other JSR. This problem domain is squarely the purview of JavaServer Faces.

2.7 Please give a short description of the underlying technology or technologies:

See 2.1 above.

2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.faces

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?

The Java SE security model is perfectly sufficient for the needs of this specifiation. There will be security related features in the specification, but these will build on top of the current security model.

2.11 Are there any internationalization or localization issues?

Faces technology deals with internationalization and localization. This version of the specification will expand this support to the realm of Ajax based applications.

2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

Yes. The specifications for the following technologies will certainly be impacted by this specification:

Servlets

JSP

2.13 Please describe the anticipated schedule for the development of this
specification.

Stage

Start

Finish

Author 1st Draft

7 Feb 07

9 Feb 07

Author 2nd Draft

12 Feb 07

14 Feb 07

2nd Draft ReviewedBy Sun Internal

15 Feb 07

9 Mar 07

Author 1st EG
Public Draft

7 Mar 07

9 Mar 07

1st EG Public Draft
Review By JSR-252EG

9 Mar 07

16 Mar 07

File JSR with JCP

Apr 07

Apr 07

JSR Review Ballot

Apr 07

May 07

EG Formation

May 07

Aug 07

Early Draft Review

Oct 07

Oct 07

Public Review

Feb 08

Mar 08

Public Review Ballot

Mar 08

Apr 08

Proposed Final Draft

Timed With JavaEE6

2.14 Please describe the anticipated working model for the Expert Group working on developing this
specification.

We will use the same working model as in JSR-252: primarily email discussion with occasional conference calls and other distributed team technology uses. See section 2.15 for the transparency measures we will use.

The reference implementation will be developed using an Open Source development model.

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.

We will leverage the collaborative tools provided by the java.net infrastructure. We have established the "javaserverfaces-spec-public" project on java.net. Therein, we will have a public issue tracker for tracking most issues. Any issues that absolutely must be EG private will be handled with a separate EG-private issue tracker. We will have an EG-private mailing list, and we will have a monitored public discussion forum as well. The reference implementation will be developed entirely in the public javaserverfaces project on java.net. The TCK will be developed privately by Sun. We will leverage the Early Draft feature of JCP 2.6 to allow the public to see the spec in progress.

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.

Sun will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK). The RI will be made available standalone and as part of the Java EE 6 platform. The TCK will be made available standalone and as part of the Java EE 6 CTS.

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.

Pursuant to Section 2.2.1 of the Java Community Process version 2.6, the
following is a summary of Sun's anticipated principal license terms and
conditions for the JSR, JavaServer Faces (JSF) 2.0. The business terms
for JSF 2.0 have not changed from those for JSF 1.2 and they impose no
new restrictions.

The JSF 2.0 Technology Compatibility Kit (TCK) will be available both as
a standalone TCK and included as part of the Java EE 6 Compatibility
Test Suite (CTS). The JSF 2.0 Reference Implementation (RI) will be
available both separately and as part of the Java EE 6 RI.

Non-Commercial Use

As required by the Java Specification Participation Agreement (JSPA),
the JSF 2.0 TCK will be licensed at no charge without support to
qualified not-for-profit entities. Such qualification will be verified
by the Compatibility Testing Scholarship Program. Support may also be
provided at no charge with approval of the scholarship board. For more
information, please refer to: http://java.sun.com/scholarship/.

The RI will be available at no cost under an open source license.

Commercial Use

Covers all use that doesn't fall under "Non-Commercial Use" above.

JSF 2.0 TCK Java Licensee Engineering (JLE) support, available for a
fee not to exceed $50k, is required for commercial use for each
Marketed Product which implements the JSF 2.0 specification. TCK JLE
support includes access, updates and upgrades to the TCK at no
additional charge.

JSF 2.0 RI and TCK JLE and marketing support will be made available at
no extra charge to Java EE licensees under their existing terms.

The RI will also be made available at no cost under an open source
license for commercial use.

For purposes of these terms:

Marketed Product is intended to describe a licensee's product that has
its own differentiation and marketing collateral. It may comprise one
price list entry, or in some cases multiple entries (for example, to
account for different localizations or delivery packaging). By way of
example, in terms of Sun's product line we wouldn't consider Sun's Java
Application Server to be a Marketed Product, but Sun's Java Application
Server Platform Edition, Standard Edition, and Enterprise Edition are 3
Marketed Products. Sun's Java Studio Enterprise is a fourth Marketed
Product.

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.

Some of the ideas to be harvested in this release of the specification are described in the links in the following list:

3.2 Explanation of how these items might be used as a starting point for the work.

Apache Shale

Shale Remoting provides a basis for deliving static content from the CLASSPATH of the application. This is a starting point for the "bundling associated resources" feature. Shale Dialog Manager, along with Spring Web Flow, Seam, and the JSF-Extensions flash, may serve as the starting point for the "passing values from page to page" feature. Shale View Controller will inform the features relating to the request processing lifecycle. Shale Tiger Extensions will inform the discussions related to features that use Java Language annotations to increase ease of development.

Project Dynamic Faces

Along with Ajax4JSF, Project Dynamic Faces will serve as a starting point for features relating to extending the JSF lifecycle to leverage Ajax. Dynamic Faces also has some ideas relating to elimination of the deplopment step.

Ajax4JSF

Along with Project Dynamic Faces, Ajax4JSF will inform the Ajax related discussions. Ajax4JSF also has a declarative rendering feature that will serve as a starting point for that feature in the JavaServer Faces specification.

Tapestry 5

Tapestry 5 leverages annotations and contains ideas about eliminating the deployment step. It also addresses performance.

ADF Faces

ADF Faces has a partial page refresh feature that will inform the request processing lifecycle features. It also has robust and mature skinning support for changing the style and appearance of user interface components.

Facelets

Facelets has quickly become an enormously popular view description language for Java Server Faces. This JSR aims to standardize most of what is in Facelets, including its page templating feature.

Project jMaki

Project jMaki will serve as a starting point for how to allow the developer to move as much of their UI logic into the client as desired.

Project Phobos

Project Phobos will serve as a starting point for how to support scripting on the server side.

Spring Web Flow

Spring Web Flow, will inform discussions relating to the request processing lifecycle, and the "passing values between pages" features.