Chat about the current JSF roadmap

Interview with JSF Spec Lead, Ed Burns

Chris Mayer

We chat to Oracle’s JSF Spec Lead Ed Burns about the latest work going towards JavaServer Faces 2.2, which should arrive in June.

It has become pretty quiet around JSF 2.2 since its new features were presented in November 2011. What is the current roadmap?

I’ve been trying to be disciplined about project management this time around and the current roadmap is always available. Because of the transparency rules of the JCP, which JSF has been practicing for years already, this is public information. Our current schedule has us finishing up around the first half of CY2012.

JPA 2.1. will supposedly provide support for multitenancy, which is key to cloud-based applications. Will JSF 2.2 also provide this kind of support, e. g. will there be a Tenant Scope for Managed Beans or anything equivalent that allows for separate storage of tenant-specific data?

In 2004, JSF was the first JCP spec to bring Plain Ole’ Java Objects [POJO] based inversion of control (and with it the notion of scopes as we know them today) to Enterprise Java. Since that time, Java EE has done some much needed refactoring and the concept of scope is now the domain of the Contexts and Dependency Injection (CDI) specification. We will continue to work closely with CDI spec, which is also a part of Java EE 7, and support their multi-tenant enabling features.

Multi-Templating is quite an interesting feature. As a rule, a template consists of several files. Do these templates have to be made available on the application server itself? Or is it OK to provide a reference to a web address?

The concept of multi-templating as it applies to JSF was initially suggested by Mamadou Lamine Ba and since then it has gone through some iterations on the EG. My current thinking on the topic is that templates can be packaged as jars and hosted in a maven repo and declared as dependencies at build time. A feature called “remote components” has been suggested by the portlet community, but this one is not on the radar for 2.2.

What restrictions do JSF developers have to accept when applying templates?

The essence of a template is the contract it specifies for the replacement zones. This is really no different from using a regular Facelet template. The multi-templating feature is a formalization of that to include a more rigorous specification of the metadata. Therefore, the main restriction is to play by the rules defined by the template author. Our challenge with JSF 2.2 is to be tight enough with the metadata to make the contract meaningful, while being flexible enough to let template designers be as creative as they need to be.

In Lamine Ba’s blog, the idea of a template gallery for JSF 2.2 was presented, and since then, a number of templates have been submitted to a provisional gallery. Is there a way to distinguish between different types of templates, e. g. if one template places a menu on the left side and another one places it on the right side?

Wouldn’t it make sense to distinguish between different template galleries in JSF based on their respective degree of restriction or freedom?

Yes, you’re hitting the centrality of the contract issue right on the head. While the gallery concept itself will not be a part of the spec, the necessary metadata to present a gallery including telling the user where the various page elements go (left, right, center, etc) is what we will provide.

As you may know, HTML 5 is a huge specification and it addresses many different categories of content. We will certainly not be exploiting all of it, and it doesn’t make sense for us to do so. That doesn’t mean that you can’t build an app that uses JSF and leverages all of HTML 5, you certainly can. You have to keep in mind JSF ‘s position in the stack. JSF is a server side UI aggregation technology. HTML5 is a client side UI aggregation technology. The UI generated by a JSF app can just as well support HTML5 at the component or application level, and there are several features in JSF 2.2 with respect to resources and JavaScript that make this easier. That said, we plan to address HTML5 elements in the following content categories.


JSF applications already have large amounts of metadata available to them. We need to find the best way to allow that data to naturally express itself via the corresponding capability in HTML5.

Sectioning and Heading

Just as the lightweight ontology of section values in HTML5 was obtained by searching Google for how people were using their div tags, the same idea can be applied to how people are using their facelet templates.

Form associated elements

Form based applications are the reason for most web applications and it is this category that most of the HTML5 related work in JSF 2.2 will happen. For example, HTML5 now has native slider and calendar controls, which only used to be implemented using server side processing and delivering JavaScript and images.

Are there any plans to use the new WebSocket API permitting bidirectional exchange of data between server and client (rather than classical Ajax requests)? Or to make Managed Beans methods consumable via WebSockets, so that JSF applications can be consumed from a pure HTML/JS environment?

Those and many other ideas have been discussed in the past for inclusion in JSF, but as WebSocket is just now starting its way through the JCP process, we prefer to wait a bit before introducing a dependency on that one.


This interview originally appeared in our sister publication, Java Magazin in Germany.

Inline Feedbacks
View all comments