February 10th, 2009 by Lincoln Baxter III

Java Server Faces 2.0 is in Good Hands

“The community was speaking, but until recently, nobody was listening.”

A lot has changed since May 15, 2001, when the first ballot review of the JSF 1.0 framework was just beginning. To this day, Sun’s flagship web-application framwork 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 JSF2.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 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.”1 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. 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-criticised 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 JCP? Cay Horstmann thinks that the JCP needs to be more open to the community.2

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 JSR314 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 8 years of JSF’s mis-managed life, and it would be dead forever. “Long live Struts,” Apache would tout.

New life.

But fate struck, and before I could even begin to write emails, begging for reconsideration, I got another pop-up from my inbox.

From: Dan J. Allen – Jan 10, 2:50pm

Lincoln,

Hey there. I have recently joined the JSF EG by way of my employment with Red Hat. My first action was to submit a couple of proposals to make JSF more "website friendly". After all, that is what got me interested in Seam in the first place.

In the most recent proposal, I cited the statements you made in a recent blog post. I have attached that proposal to this e-mail as well as a related proposal. We are listening (at least those of us at Red Hat) and we are trying our best to improve JSF within the boundaries that we have to work (i.e., the JCP). The JSF EG was definitely dysfunctional in the past, but Ed Burns, Red Hat, and a handful of other members have really started to turn things around. Adding pretty URLs is definitely too big of a change at this point given the time constraints, but you may find these two proposals to satisfy many of your other concerns. Feel free to provide feedback to the JSF EG regarding the design changes.

-Dan

Dan is the author of Seam in Action, and from my interactions with him, a brilliant individual. If he isn’t rich already, in heart or on paper, he will be someday.

Struck by two emails on this subject in the same day, I “hurriedly” (from 11pm-2am) typed a response. Someone at RedHat was asking me for my feedback? Talk about an ego trip. My friends at work won’t let me hear the end of it.

The proposal was stunning. While still omitting Pretty URL rewriting, it contained in depth solutions for using query-string parameters (http://url?key=value) to bookmark pages within JSF. It lacked page-load actions, but that would follow, as we talked through the issues, in the next few days.

During the process of reviewing Dan’s proposals, providing feedback where I could, and wishing I weren’t just a part-time contributor, we worked through issues regarding usability, convention over configuration, and strategies for implementing the new functionality that would be required. Two weeks and 91 emails later, we had a draft of the spec, and off it went (via Pete Muir at RedHat) to the Expert Group for review.

The proposal was accepted; Dan’s job got even better. Within a week, he would have to implement his proposed specification, create a sample application, make any necessary changes to the spec, submit it back to the EG, and believe me, it was good.

Things yet to come.

JSF2 is still under review, and all of these changes may yet be changed, but I’m confident that the people in charge have heads on their shoulders, and that they are pointing in the right direction.

I’m impressed. Impressed by Dan Allen, Jim Driscoll, Ryan Lubke, and by Sun for starting to recognize that its developer community is its best chance at survival. JSF2 won’t have everything that we’ve asked for, but it will have the most critical features that the community has asked for. I’m impressed that it’s turning out so well: Component writing is truly easy; pages will be bookmark-able; templating is built in; and annotations are on the way to deprecating faces-config.xml for trivial tasks.

So what can Sun do next? Well. For starters, keep listening. Don’t limit ideas to people on its payroll. JSF2 will be a success if Sun gives users a voice.

The developer blogs are great, but we need a centralized place for core documentation. The site needs to be fast, and you should be able to easily register and contribute. Yes, it will take management and oversight, but we aren’t out to hurt anyone. Dear sun: “We like what you’re doing, and the direction in which we think you might be turning. We’re here to further the cause of software development, and guess what… If you listen to us… we’ll do it for free.”

Whether or not this happens, the future of JSF is in our hands.

1http://www.jcp.org/en/jsr/results?id=614 2http://weblogs.java.net/blog/cayhorstmann/archive/2009/01/a_call_to_fix_t.html

Posted in Java, JSF

6 Comments

  1. Interesting and well written

  2. Chris Hansen says:

    For someone spending as much time with JSF as you clearly do, I hope you’ve taken a serious look at Wicket. If not, I think you’re doing yourself a disservice.

    I’ve used JSF for a couple of years now and been (ignorantly) content, and now I regret not looking into Wicket sooner. You owe it to yourself to at least give it a serious try.

    1. wil says:

      Agreed. Encourage Java programmers to at least take a look at and try Wicket. Its programming model is more natural, at least to me.

  3. After much Googling, I found your post to be marvelous on JSF 2.0. I have been behind many technologies, Spring MVC, Wicket etc. trying to figure out speed, development ease, re usability and possible integration with a rules engine. Sticking to core java technologies always paid off. I am still concerned about the performance metrics of jsf 2.0. If that is sound, I think we’ve got an elite framework to do web on. Any news on performance?

  4. Nepoez says:

    To me, JSF combined with SEAM helps me produce web apps in the least amount of code compared to other frameworks out there. It’s also very fun to write. The problem is as fun as it is, the performance is also the worst of anything else I’ve tried.

    Oh yeah, it’s also very easy to break a JSF app with back buttons.

Leave a Comment




Please note: In order to submit code or special characters, wrap it in

[code lang="xml"][/code]
(for your language) - or your tags will be eaten.

Please note: Comment moderation is enabled and may delay your comment from appearing. There is no need to resubmit your comment.