Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JW Soapbox: JavaServer Faces 2.0 is in good hands

The community speaks, and it appears Sun is learning to listen

  • Print
  • Feedback

JW Soapbox is a community forum for talking about what matters in Java-based software development today. In this first Soapbox column, PrettyFaces author and OcpSoft Principal Lincoln Baxter III reflects on his experience of getting involved with JSR 314: JavaServer Faces 2.0.

A lot has changed since May 15, 2001, when the first JSF ballot review of the JSF 1.0 framework was just beginning. JSF to this day -- Sun's flagship Web-application framework -- has been an uncompromising box of tricks and gotchas, with little community adoption. This has been mostly due to its relatively developer-unfriendly nature; however, the second phase is coming, and with JSF 2.0 peeking out from the edge of its nest, a new life is beginning to show.

From the start, JSF had mixed support from the community, with opposition from major players like IBM, HP, and the Apache Foundation. Apache voiced strong concerns with the new JSF, because of "Sun's current position that JSRs may not be independently implemented under an open source license." In addition, they saw "little value in recreating a technology [Struts] in a closed environment that is already available in an open environment."

Apache's concerns drew several other players to vote against JSF, but the final vote still passed with a 10-5 margin (Accenture abstained from voting). With the voting complete a short two weeks later, the first JSF expert group was formed.

This article was originally published on the OcpSoft Blog, on February 10, 2009.

Three months after the formation of the expert group, the first JCP community review was complete, and Sun's new star Web-framework was on its way to reality. On the side of the box was a label, which read, "Final release, May 2004: Warranty Void if Removed" It was done, and their hands were off.

But some things that should not have been forgotten, were lost

Since JSF was engineered by companies like IBM and Oracle, major contractors in the industry, most of the emphasis was placed on creating a modular architecture that could be "easily extended" and broken down into components. While technically sound, and well designed for large companies where developers are part of an assembly line, the community at large found JSF hard to use.

JSF lacked life-cycle extension; there are six defined phases, and if you need to add another one, you're out of luck. Also lacking was easy component creation -- Creating a component in JSF today requires modification of no fewer than four separate files, even more if you use a separate renderer class. You were on your own if you wanted to validate multiple form fields against each other.

Navigation rules were ungainly, and difficult to follow logically without a visual editor. Community documentation was almost a joke. Sun's mailing list and forum are still the best places to find help. There are some very knowledgeable people, but nowhere to be found is what most developers find most useful: a central, persistent resource for documentation. I like PHP's model -- official documentation with community feedback in comments below.

The lack of bookmarking support is one of the most highly-criticized facets of JSF, which is where I got involved, leading me to create the PrettyFaces URL rewriting extension. If you need to be convinced of the collective dysfunction on this topic, look at the results of a Google search for "jsf bookmark." Yet, at the root of all this was something JSF lacked until very recently -- something very important.

A set of ears

The community was speaking, but until recently, nobody was listening. Blame the JCP? Cay Horstmann thinks that the JCP needs to be more open to the community.

Personally, I'm surprised that JSF wasn't abandoned completely, which says in my mind, "they got something right." The framework does a lot for you, but "I can't figure out how to use it," "it doesn't do what I need," and "everything takes forever." This is where we see the light, and JSF2 enters from stage left; a new star performer?

From the very start, JSF2 is different, more open. Ed Burns, Ryan Lubke, Jim Driskoll and other blogging developers can be thanked for engaging the community in a way that Sun has not done before.

Convention over configuration has taught us a lot. We might thank Ruby on Rails, or possibly a collective laziness, but the JSR 314 Expert Group has taken it to heart. "EzComp" is JSF's new component writing system, and yes, it's "Ez."

Jim Driscoll explains how to create a "click to edit" Ajax input field, like those so popularly seen on Flickr or Facebook. (About 30 lines of XHTML, plus JavaScript.) Tag libraries no longer need to be defined manually; they will spring to life as needed, based on the names and interfaces of your components.

JSF2 is showing stunning promise and vision. This is just a small set of changes that will drastically improve the usefulness and adoption of JSF. When a rookie Java Web-developer can pick up JSF2.0, in their IDE of choice, and write a small, useful application in a day, that's when we'll know they've gotten it right. Man, life is good ... but.

Where are my bookmarks?

Ahh yes.

After learning about JSF2 in mid-October, I've been following very closely the changes and discussions around its new architecture, and how it can be "fixed." At the top of the wish list, among other contenders like "Fixing Navigation Rules," and even above "Simplified component development," is one very near to my heart: "Enhanced support for GET requests."

I began work on PrettyFaces before learning that JSF2 was in progress, but not before I had evaluated the other options available from the community. JBoss Seam had a UrlRewriting feature, but I found it cumbersome, requiring too much configuration, and the added burden of learning the entire Seam framework was too much for me. RestFaces was an alternative that I tried for a while, but several design choices made it difficult to incorporate in a non-invasive way, and I was left writing lines and lines of code in order to compensate for its (albeit few) shortcomings.

Shocked, disappointment struck when I was contacted by a PrettyFaces user, disheartened, who urged me to contact the JSF2 expert group because they were close to abandoning bookmarking support for the next release, a full five years after the last specification update. How could they be considering omitting such a critical feature? It would surely finish off whatever damage had been done by the first eight years of JSF's mis-managed life, and it would be dead forever. "Long live Struts," Apache would tout.

  • Print
  • Feedback

Resources

More from JavaWorld