JavaOne 2008 – The upcoming JavaServer Faces 2.0 specification – time to harvest!

JavaServer Faces has been around since 2004. The current release is 1.2. Work has started to produce the 2.0 release which will be part of JEE6, which is slated for Late 2008/Spring 2009. I attended a presentation by Ed Burns and Roger Kitain, both from Sun and both co-leader of the team that develops this 2.0 specification. The first draft of this spec is about to be published, next week (May 13th), and will be open  for review during 30 days.

They discussed – for a packed room – what is going to be the essence of this major new release. One very important realization is that this release is primarily about harvesting innovations seen in the JSF eco system in the last few years – and not about innovating and creating a lot of new functionality out of nowhere. Other core elements in this release are interoperability between JSF libraries from different vendors, support for AJAX, more convention over configuration (so less configuration effort), use of Page Description Language/support for Facelets and much easier development of custom components.

They spent some time in the beginning of the session to establish that JSF is pretty well established by now. They listed the large number of JSF libraries available from various vendors and open source projects, a number of real world applications – including some internet applications – using JSF and the number of job postings that been increasing for the past few years (although it experienced a slight drop in recent months, especially relative to Rails…). JSF is now supported by all major IDEs, allowing for relatively productive development supported by drag & drop, code completion, declarative property editors and visual editors in most cases. The uptake JSF has seen has been substantial – also given the number of attendees in room raising their hands – and is further increasing. The fact that JSF is part of the JEE platform is of course a pretty important factor in this. Surprisingly, to me at least, Ed and Roger failed to mention that Oracle is building its Fusion Applications using JSF technology – and they will be hard pressed to find a more complex and substantial JSF development effort. I can think of no better proof of JSF’s maturity. Ed and Roger mentioned that JSF seems to have a stronger presence in Europe than it has, comparatively, in the US.

Of course the last few years of building applications using JavaServer Faces has provided a lot of insight in some shortcomings of the technology as well. Some are limitations of JSF itself, others are the result of developments in the environment. The quick evolution (or is that called revolution) of AJAX and RIA libraries has had and will continue to have a profound effect on Web Applications and the way they are developed. JSF does not currently provide optimal support for that.

Developing JSF applications does not really allow developers to ‘stay in the flow’. Instead of developing interactively, reviewing the effect of each change instantly, they are required to continuously redeploy the application to the application server, which typically takes some time. This is one of the area where the development experience should be improved and become more lightweight and straightforward, such as for example with (Ruby on or G)Rails.

Development of JSF components by developers themselves – in addition to vendors and specialized open source teams – proved to be too hard. Various vendors created wonderful JSF libraries with most of them providing a proprietary solution for the AJAX challenge. Primarily because of those AJAX mechanisms, most libraries do not go together very well, with the notable exception of MyFaces Tomahawk that seems to be able to mingle with almost all of the other JSF libraries.

The speakers also mentioned some of the other activities surrounding JSF, such as the Facelets initiative, of which a large majority of the room was aware, and supporting tools such as

• JSFUnit (out of JBoss, see http://www.jboss.org/jsfunit/ ) ;
  JSFUnit is a test framework for JSF applications. It is designed to allow complete
  integration testing and unit testing of JSF applications using a simplified API. JSFUnit tests run inside the container,
  which provides the developer full access to managed beans, the FacesContext, EL Expressions, and the internal JSF component
  tree. At the same time, you also have access to parsed HTML output of each client request.
• FacesTrace (http://facestrace.sourceforge.net/ ) :
  FacesTrace is an open-source library that aims to enhance
  the traceability of JavaServer
  Faces based applications. Several trace information and performance metrics
  are collected and presented on the page being traced.
• DynaFaces (http://swik.net/DynaFaces  or https://jsf-extensions.dev.java.net/nonav/mvn/ ) DynaFaces is a thin layer on top of JSF 1.2 that provides clean Ajax integration. It is based on the Avatar idea from Jacob Hookom.
• JSFTemplating (https://jsftemplating.dev.java.net/ ):
  Templating for JavaServerâ„¢ Faces Technology plugs into
  JavaServerâ„¢ Faces to make building pages and components
  easy.
  Creating pages or components is done using a template file.
  JSFTemplating’s design allows for multiple syntaxes, currently
  it supports 2 of its own plus most of the Facelets syntax. All
  syntaxes support all of JSFTemplating’s features such as
  PageSession, Events & Handlers, dynamic reloading of page
  conent, etc.

Main themes for JSF 2.0

Make it easier for developers to create custom components. Simple by creating a bit of XHTML, possibly with some additional resources and bundling them in the right way should be enough. It reminded me a lot of the Widgets in jMaki, and apparently this approach is inspired by JSFTemplating. It certainly seems a much faster and simpler way of defining JSF Components.

Using Facelets – XHTML files with additional JSF markup – (While JavaServer Faces and JSP are meant to be aligned,Facelets
steps outside of the JSP spec and provides a highly performant, JSF-centric view technology.
Anyone who has created a JSP page will be able to do the same with Facelets. The difference
is under the hood where all the burden of the JSP Vendor API is removed to more greatly enhance
JSF performance and provide easy plug-and-go development.) it should be much more straightforward, for human developers – and designers – as well as code generators and tools, to create page definitions.

Reduce the configuration burden: less configuration, more sensible default values that will cover the majority of situations and support for annotations to specify components, validators and all other artefacts.

An important part of the support for AJAX (as well improving performance for general page loading scenarios) is the Resource Delivery Mechanism. Delivering resources will be part of the JSF 2.0 lifecycle. The HandleResourceRequest step in the life cycle will replace the normal page oriented flow through the lifecycle and take care of serving up the actual resource content (GIF/JPEG, Javascript Library, CSS document,..). It delivers static resources to the user-agent in response to HTTP GET requests. The resource delivery mechanism includes support for localized, versioned resources and resource libraries.

Another element in the AJAX capabilities will be the Partial Tree Traversal – inspired by DynaFaces, mentioned above. This will allow a page to do a request that is not a normal full blown page level JSF lifecycle request. Instead, it allows a page to do an AJAX request that will only reconstruct a treefragment identified in the request and only render the HTML for that particular fragment. Obviously, such a request can be much more efficient than a full page refresh.

JSF 2.0 will have AJAXification through a AjaxZone tag that can be used to embrace (or wrap) existing components, in order to be able to AJAX-enable them: to give ajax capability to existing JavaServer Faces components without writing any JavaScriptâ„¢ language.

Partial Page Update – already available in a proprietary implementation in many JSF libraries – allows an AJAX style request to only rerender (DOM manipulate) a small section of a page. This too will be supported in a standardized manner.

In addition to all this, there is talk about a set of AJAX enabled components with the Reference Implementation. and to provide a generic approach that will lead to better compatibility between JavaServer Faces component libraries from different vendors. The JSF Specication Team is working with the OpenAJAX Alliance in order to create shared vision and a common approach for dealing with AJAX within the JSF libraries.

Part of this effort will be the registration and leveraging of namespace javax.faces.ajax. There will also be a JavaScript library, that provides at least Partial Submit, Partial Rendering and some Utility functions: Collect/encode/return client JavaServer Faces component View State
(to be used in POSTBACK or Ajax request), Given JavaServer Faces componentId or clientId, return client DOM Element corresponding to outermost markup for that component. Implementing Server to Client push – for example the Comet technology – is “on the radar”. The presentation mentioned ICEFaces, Dynamic Faces, Richfaces and AJAXFaces as the sources of inspiration. Looking at some of the work that done, I find it hard to believe that not either ADF Faces or Trinidad has provided some input for this Design In Progress for 2.0.

Other goals for JSF 2.0:

• State management rewrite
• Bookmarkable URLs
• Zero deployment time
• Tree traversal
• Scopes
• Extension prioritization
• Better error reporting

Finally, it will work well with WebBeans and it will work well with Portlet 2.0.

Resources

Ryan Lubke’s Blog: http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature5  and http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2 .

GlassFish Mojararra for the required sources: https://javaserverfaces.dev.java.net/