Main Menu

The Fit and Finish of JSF

When I come
across an article such as
href="http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/">this one, I am
overcome with melancholy. I really want to love JSF. Its heart is in the right
place. It wants to let me drag and drop components onto a form, wire them up
with JavaBeans, and give me AJAX with essentially no work on my part. And it
comes so close.

Now, admittedly, I am biased. I am a co-author of the best-selling JSF book,
with David Geary, published by Sun Press. I am making lots of pennies on the
Safari page views and a few dollars from the hardy souls who, bless their
hearts, still buy the paper version. But frankly, there are easier ways of
making a buck than writing a JSF book. I wouldn't do it if I didn't think JSF
was (or, at least could be) the cat's pajamas.

We all know that JSF is far from perfect. Too much stuff in the HTTP
session. Component authoring is way too hard. A leaky abstraction. The stack
trace from hell.

But what really bugs me is the overall lack of “fit and finish.”
Sometimes, JSF feels like one of those lower end American cars that make up
much of the rental car fleet. Cheap, mismatched buttons. Gaudy metallic plastic
that comes off when you stare at it too hard.

Here is a random example, one of many:

JSF 2.0 has a new feature for locating resources. It's pretty nice. You dump
images, CSS files, scripts, and so on, into subdirectories of aresources directory. Then you can write

&lt;h:graphicImage library="images" name="myimage.png"/&gt;

Or, as my coauthor inexplicably prefers,

&lt;h:graphicImage value="#{resource['images:myimage.png']}"/&gt;

As it happens, I have a command button with an image. Wanting to be
thoroughly modern, I move the image to the resources directory.
Oops, h:commandButton hasn't been fixed to havelibrary and name attributes. No problem:

Of course, it doesn't work. The value ofresource['images:myimage.png'] is/context-root/faces/javax.faces.resource/myimage.png?ln=images,
which starts with a slash! (Can you hear the evil laughter in the
background?)

The JSF 1.0 expert group had to worry about big and important things such as
the pluggability of the state manager, and nobody paid much attention whenh:graphicImage added the context root to an image URI andh:commandButton didn't. The 1.2 expert group, focusing on lofty
issues such as the ability to have multiple render kits in a single
application, apparently had a few minutes to spare on a “solution”.
Now h:commandButton prepends the context root if the image URI
starts with a slash. So, I get/context-root/context-root/faces/javax.faces.resource/myimage.png?ln=images.

I know, it's no big thing, and I can work around it. It's just like that
rattling piece of plastic in the rental car.

And I don't want to make fun of the JSF expert groups. They are very
knowledgeable and have solved hard problems in constrained time frames.

My beef is with the process.

A JSR is formed

The expert group goes to work

An early draft and a reference implementation are posted to the
public

The spec is incomprehensible to those who haven't participated in the
discussions

With much effort, the early reference implementation can be coaxed into
running some nifty examples

A few blogs appear

It becomes apparent that large parts of the promised deliverables are not
yet specced or implemented

In a few short months, a very large amount of new technology is added to
the public review draft

The spec is still largely incomprehensible

The reference implementation is getting almost usable

There are still important pieces missing that look pretty dicey to spec
and implement

The expert group, in a burst of heroic action, provides most of the
missing pieces and issues a proposed final draft.

The spec is still filled with gobbledygook, but it has become familiar
gobbledygook

The reference implementation has become pretty stable

Bloggers, authors, tire kickers, and early adopters can finally make
sense of the thing

The final draft is rubber-stamped

Lots of little “fit and finish” issues become apparent

None of them can get addressed because the spec is final

All behavior must now be preserved in the interest of backwards
compatibility

With this process, cruft is bound to accumulate. JSF is not the only
culprit. Apparently,
href="http://blogs.webtide.com/gregw/entry/servlet_3_0_proposed_final">all is
not well in the land of servlets. And that's a much simpler spec.

I think the process needs a couple of tweaks

“Public review” should not be mere lip service. Give at least
6 months between issuing the proposed final draft and approval. Have a
formal process for collecting input and responding to it.

There should be a process for cruft detection and removal in every
update. Deprecate in version x + 1, remove in version x + 2.

Again, I don't want to bash JSF. There are lots of nifty things in JSF 2.0,
and I see no really compelling alternative to it. (If there was, everyone would
just flock to it instead of kvetching about JSF.) I just want more fit and
finish in JSF 2.1 and 3.0.

Comments

I wholeheartedly agree with what you said about fit and finish and how some of the smaller details that matter are overlooked while more complex issues are focused upon. I've noticed this with JAX-WS/JAXB were basic interoperability with other systems like WCF doesn't work, but, the people developing the technology seem to already be focusing all their efforts on other more complex standards. An example would be not being able to mark method parameters and return values as nillable. I don't know how something like that could have been overlooked to begin with. In JSF I would like to see databinding more akin to Flex or Silverlight where you don't need to use special classes such as DataModel. I didn't see any mention of that in the new JSF spec. Usability and fit and finish definitely seem to be overlooked on a lot of fronts in the Java world, not just JSF. Personally, I would like to see the Java community implement a lot of what Microsoft has been doing in terms of ease of use. Luckily IDEs like NetBeans have gotten quite good and are competitive to Microsoft's offering, Visual Studio. However, there are a lot of quite useful features in .NET now like partial classes, properties, events, etc that make things a lot nicer to work with that are missing from Java. I don't know what the deal with JDK 7 is and why it's taking so long to come out. Also, I'm worried that when it does come out a lot of what I'm hoping will be in it in terms of ease of use will still be missing. Also, there are longstanding issues like Tomcat always throwing OutOfMemoryErrors on web app redeploys that at the current rate I NEVER expect to be resolved. It seems absolutely ridiculus to me that this issue wasn't resolved YEARS ago. It makes you question the whole process of having multiple vendors design all this stuff. As far as JSF goes I will be amazed if JSF 2 acheives the ease of use that Microsoft had with ASP.NET back in 2005 or before. And while I'm complaining about everything else, I don't know why Sun had to create a whole new language for JavaFX. Why didn't they just copy Flex and Silverlight and create something like XAML for defining the UI and use a code behind file in Java for the backing code? I can't believe that while Applets have been out for over 10 years that all the sudden Flex and Silverlight are making a joke of it. Java should be the leader here. There are other stupid things like you have to sign your applet if you want to call a web service from it using JAX-WS. This is because JAX-WS reads a system property which isn't allowed in an unsigned applet? Requiring signing for something as simple as making a web service call is absolutely ridiculus and goes back to the lack of fit and finish and usability testing in Java. There are too many road blocks like this and it wastes a lot of developers time. I have had a lot easier time when working with .NET because Microsoft seems to pay much closer attention to the big picture and making sure everything works together as a whole.

Cay,
Fair enough. Getting something out in front of people sooner would probably help a lot. FWIW, I think we'll see MUCH more transparency with 2.1, so maybe we can achieve that.
If you have examples of the gobbledygook, perhaps we can fix (or clarify) those in 2.1. An issue filed against the spec on the issue tracker would help, if you have time for that.
Thanks for all your help.
I'll see if I can find you at JavaOne. ;)

Hi Jason, thanks for the quick response.
The expert group always complains that everyone waits "until the last minute", but I don't think that's quite true. It is genuinely difficult to do much complaining until you have a chance to kick the tires, and that requires a reasonably working RI. I am working on the third edition of Core JSF, and it's been the same thing every time. I am very motivated to get the book out as soon as possible, but by the time that I am in a position to suggests meaningful improvements, everyone is either in a mad rush to finish the remaining major features, or the window has passed. I still think that a formal feedback process would do some good.
I wish the spec was uniformly precise and pedantic. I have read many specs in my career, and I am sorry to say that the JSF spec is not of the highest quality. When I say "gobbledygook", I mean those parts that are simultaneously dense and vague. Another symptom of the mad rush to finish.
Like I said, you guys do amazing work, but I really wish that there was a bit more time for "fit and finish" built into the process.

Hi, Cay. Loved Core JSF 2nd ed, BTW. :)
To the point, I think you raise some valid concerns, but I'm not sure I agree with all one of your conclusions. (I should note, probably, that I'm on the JSF 2 EG in case that matters. Probably not, but you never know :) I think a better emphasized public review might be helpful, but I don't think a 6 month window would work. IMO, we've moved a bit slow in getting 2.0 out the door, though most of that was probably due to the long delay in forming the EG. I think there's ample support for moving more quickly on 2.1 and beyond, so that may help.
The review process *could* probably use a bit more emphasis and, dare I say, formality. We got lots of good feedback during the process, but, given the number of late responses, it seems most people don't bother to look until the last minute. A longer window, then, might not be all that effective. Secondly, I'm not sure how many people are really interested in reading specs that aren't already involved to some degree in the process. As a JSF user, I never read the spec until I started working on Mojarra (that's what your book was for ;). Perhaps that's due to all the "gobbledygook" that goes into a spec, but a spec that lacks precision and pedantry makes it hard to have compatible implementations, it seems to me, so that gobbledygook is somewhat unavoidable. I don't know that much can be done on that front.
On cruft removal, though, I'm solidly on your side. I'd like to see all kinds of cruft removed from all sorts of specs (the Java language, for example). One can't be capricious when removing features/support, but for old, rarely used items, there's little value in maintaining their existence.
At any rate, thanks for the "meta-feedback." I look forward to reading the next edition of Core JSF. :)