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
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
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.
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.
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.
(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
â€¢ Extension prioritization
â€¢ Better error reporting
Finally, it will work well with WebBeans and it will work well with Portlet 2.0.
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/
2 thoughts on “JavaOne 2008 – The upcoming JavaServer Faces 2.0 specification – time to harvest!”
With the contributions of the expert group, the JavaServer Faces APIs are being designed so that they can be leveraged by tools that will make web application development even easier. Several respected tools vendors were members of the JSR-314 expert group, which developed the JavaServer Faces 2.0 specification
Hi Lucas, thanks for this post, I’ve been looking for a good JSF2.0 write up for sometime.
Given Oracle’s adoption of JSF, and in a number of cases technology solutions over and above the current JSF specs, do you believe the next JSF spec will require Oracle to rework significant parts of their solutions to remain standard compliant? For example you mention the adoption of the partial page update by JSF 2.0, something which Oracle has had in their own (proprietary) solutions since UIX. In other words, and my larger concern, will we see another large rework of Oracle’s component set in a future release?
Comments are closed.