JSF sucks

This post is intended to be a reference for those evaluating or contemplating using JSF. Once in a while, I find myself having to convince people that there are far, far, better alternatives to JSF. With this blog post finally in place, from now on I will probably just refer people here. Please pass this link on to those you feel will benefit from this fairly large selection of links and real-life experiences collected from across the interwebs. And if you have any more such links, do let me know in the comments.

Update: [2010-01-23] – Ed Burns, co-spec lead for JSF has just posted a detailed response to this blog post here:

A Response to Peter Thomas’s JSF Critical Screed

Readers are encouraged to also read the other side of the argument there and form their own conclusions.

My 2c:
Clearly, many architects recommend JSF as a “safe choice” for new projects just because it is a “standard”. All I’ll say is that there is more than enough evidence to prove that JSF is flawed in some significant and fundamental ways – especially compared to available alternatives.

We all know what happened to EJB 1.X / 2.X. Will JSF go the same way?

You read and decide.

[2004-03-04] JCP Releases JavaServer Faces 1.0 – JSF 1.0 approval is announced on TheServerSide, not many people sound impressed. The negative reaction (along with quotes) is summarized in this Internetnews.com article: Programmers So Far Underwhelmed by JSF. Quote from the article:

The Java Community Process (JCP) has approved a standard for building Web applications at the presentation layer, but the reaction of some programmers so far is that it adds another layer of complexity while delivering nothing they can use.

[2004-03-05] JSF: The Ultimate in Flexibility? Or Complexity? – JDJ article by Steve Benfield. Quote:

What I see in JSF is overengineering. Let’s think of every possible usage pattern for Web pages and address them, not necessarily a bad thing. The resulting standard is one in which there are several layers of abstraction, many, many moving parts, and ultimate flexibility.

[2004-06-09] Improving JSF by Dumping JSP – O’Reilly / OnJava.com article on one of the problems that has plagued JSF for a long time and many unfortunate teams (who don’t use Facelets) face even today. Keep in mind that this article is from 2004. Quote:

Don’t get me wrong: I like JSP and I like JSF. I wouldn’t have spent so much time contributing to the specifications and writing books about these technologies if I didn’t think they had value. It’s the combination of these two technologies that I don’t like, because they don’t complement each other in a natural way.

[2004-08-06] My JSF Experience – blog post by Matt Raible. Some follow up discussion here where David Geary (JSF EG member) admits that JSF is not perfect. Quote from Matt’s blog post:

Whatever you do, don’t use JSF. Not yet anyway.

[2004-09-20] Boycott JSF – blog post by Hani Suleiman (who currently happens to be a JCP Executive Committee member). Quote:

So I beg of you all, don’t use JSF, boycott it, avoid it all you can. Do not let it thrive or prosper. We don’t want it improved or tweaked, we want it to die the horrible painful death it so richly deserves.

[2005-07-??] Gradebook – Taming JSF 1.1 – an article / wiki page by Ray Davis detailing the problems faced by the Sakai project and how they had to work around some of the issues faced. The content here can be considered somewhat outdated (relates to JSF 1.1) but serves to highlight the elementary problems that JSF has had in initial versions of the spec itself. Some commentary also on other blogs here and here.

[2006-01-20] JSF Burrito: More Complete List – commentary and a list of JSF pain points by Tim Shadel. Part of a series of blog posts – read the others here, here and here. Quote:

Ultimately, JSF provides a Leaky Abstraction that (in spite of its promise) still requires all developers to understand Request-Response in addition to the 6-layer lifecycle. (”Response already committed” error, anyone?)

[2006-02-10] JavaServer Faces – why? – discussion thread at “Joel on Software”. Quote:

I’m a complete JSF newbie, and I’ve been trying to hack together a small demo app. I’ll spare you all the gory details but long story short I _hate_ JSF. Hate it, hate it, hate it. I honestly can’t imagine how anyone at Sun could ever imagine this as a competitor to ASP .NET.

[2006-02-21] Usability problems in JSF – blog post by Adam Winer. Quote:

A second category of annoyances in JSF consist of “nothing happened” problems. For example, if a validation error stops you from going on to Invoke Application, but you’ve forgotten to add an tag or something similar to your page, all that you see is – nothing.

[2006-05-03] Where JSF and Portlets went wrong… – blog post by Jevgeni Kabanov, founder of the company that makes JavaRebel JRebel. Some follow up discussion on JavaLobby here. Quote:

What’s worse, JSF have imposed on us a highly complex and clumsy API, that one needs to follow to achieve even a little reusability and broke the familiar way of capturing logic in custom JSP tags.

[2006-05-19] JavaOne: Google Web Toolkit vs. JSF – blog post by Bob Lee, creator of Google Guice. You can’t help thinking – if JSF is so great as the vendors / authors / evangelists would have you believe – why are there so many competing Java web-frameworks? Quote:

For the majority of intents and purposes, GWT invalidates JSF. Both frameworks seek to isolate web developers from HTTP, but due to the fact that Google built GWT from the ground up with AJAX in mind, GWT offers a cleaner abstraction, better type safety, and a lower learning curve. When it comes to AJAX and JSF, you’re at the mercy of which functionality your JSF components offer.

[2006-06-19] JSF Rough Spots – blog post by Don Brown compares JSF and Struts 2, talks about how JSF is more verbose and cumbersome to use.

[2006-06-20] RE: What Web Application framework should you use? – blog post by Matt Raible, and the comments are well worth reading. Quote:

JSF continues to be the most over-hyped under-used framework in Javaland. If you read the blogs of first-time users, you’ll find many complaints and issues on how things work.

[2006-09-08] JSF and RSFHistory – wiki page detailing some of the issues with JSF that led to the creation of RSF (Reasonable Server Faces). Quote:

I could go on about JSF’s other architectural deficiencies (firstly the existence of FacesContext, and secondly the global access to it which is the most utter destroyer of testability, thirdly the crazy table rendering model, fourthly the fragile and untrustable PhaseListener system, fifthly the lack of any coherent policy wrt. exceptions &c), at some length, but I will move on :P

[2006-09-13] Geebis Blog: Wicket – blog post by Caleb(?) that discusses experiences with Seam / JSF and how Wicket appears to be better. Quote:

The biggest reason is that creating custom components in JSF can be difficult, especially if you want your components to have lots of javascript/css that it contributes to the page. JSF requires that you use a writer to send your component’s HTML to the browser. With this system you end up with spaghetti code that’s hard to debug, and hard to test. Add ajax functionality to the mix and you have a featureset that JSF just can’t handle in the current version.

[2006-09-16] Tinman and the Scarecrow – blog post by Dhanji Prasanna, Google Wave Core Engineer and creator of the Google Sitebricks web-framework. Quote:

It is no secret that JSF is made for tool vendors. However, it is somewhat possible to get away with working with JSF by hand only (in fact Ive done a fairly large project this way), though this is neither on par with using tools nor easy as many proponents claim. Principally, it is not fun and doesnt offer as much reward to a developer for effort spent hitting keys.

[2006-10-19] MyFaces: The emperor has no clothes – a detailed blog post by Ignacio Coloma. Of all the many rants against JSF out there, I would pick this as my favorite. It deals with the author’s experiences with JSF on a real-life project and goes into the technical details of various issues. A must read. It looks like Ignacio Coloma was so disgusted with JSF that he later decided to create a new Java web-framework called Loom. Quote:

I do not have enough space here to explain the hell that developing a custom component is, so will leave a short summary: you will be fine if you are doing a simple stupid component that is shown as a single textfield, and there are big, red, horny demons in your way if you try anything more sophisticated.

[2006-12-15] Nightmares on JSF Street in Trinidad – blog post by Rainer Eschen. Quote:

If you keep in mind that Sun started in 2003 to talk about the JSF specification in the public, we hear and talk about JSF for three years now. If I have a look at the results, I’m a bit disappointed. This is comparable to the Swing development and the missing practical GUI designers (for years).

[2006-12-19] Reasons to choose Wicket over JSF and Spring MVC – InfoQ article on experiences evaluating web-frameworks. Quote:

I liked [JSF's] form handling and navigation support but I did not like all the javascript and extra markup that was inserted into every page without me asking for it.

[2006-12-26] not enamored by JSF 1.1 – great rant by Timothy Stone on the JavaRanch forums. The whole thread is worth reading. Quote:

The RI of JSF v1.1 hijacks and pollutes the id attribute of HTML for its own use, thus rendering CSS stylesheets almost useless and making work with the DOM in Javascript a PITA. This is probably the single greatest problem I’m staring down the barrel at.

[2007-01-01] JSF in 2007 – O’Reilly.net / ONJava article by Shashank Tiwari. This promptly triggered a lively debate on TheServerSide here.

[2007-01-18] Tech Talk: Ed Burns on JSF 1.2 yet another discussion of JSF issues ensues on TheServerSide.

[2007-02-19] JSF is cool but it is too young and it has too many bugs! – yet another forum thread on JavaLobby. Quote:

I’m very tired, I spend the double of the time to develop this because of the problems I had to check out on the net, maybe I will wait for JSF to become better and for now use other technologies.

[2007-02-28] JSF Anti-Patterns and Pitfalls – article on The Server Side and discussion here. The article opens with these words:

This article covers anti-patterns and pitfalls of day to day JSF development. Most of these issues have kept the author up at night; some of these are the same old challenges with a new face, pun intended. These challenges include performance, tight coupling, thread safety, security, interoperability and just plain ugliness.

[2007-03-17] JSF – Still pretty much a steaming pile of donkey turd – another classic rant by Wille Faler. Wille has since embraced Wicket and went on to initiate the Wicket RAD project. Quote:

The end impression is that it is a horribly convoluted, over-engineered framework that goes to great lengths to replace existing, well functioning technologies without addressing any of the pain-points at all.

[2007-04-16] JSF still sucks? – by Matt Raible, creator of AppFuse and someone well respected in the Java community especially for his web-framework comparisons. Quote:

Conclusion: don’t use JSF simply because it’s a “standard”. Use other frameworks that are more actively developed and designed for the web. For component-based frameworks, the most popular are Tapestry and Wicket. Less popular ones are RIFE and Click.

[2007-04-26] Creating a jsf div component – blog post by Andrej Koelewijn. The amount of code and effort that is required for just creating an HTML DIV is to be seen to be believed. Discussion on TheServerSide here.

[2007-05-14] A Wicket user tries JSF – a side by side comparison of JSF (MyFaces) with Wicket by Peter Thomas. Lots of discussion in the comments. Quote:

JSF is supposed to be a component oriented framework but I wouldn’t call them Java components and definitely not Object Oriented.

[2007-05-22] Rethinking JSF – The Real Problem – after a flurry of JSF-bashing blog posts appearing in early 2007, Joseph Ottinger (then editor of TSS) attempts to do some damage control. But the ensuing discussion thread is a good read with some gems in it like this one comment by Leo Lipelis that does a great job of listing and explaining a bunch of JSF issues. More discussion can be found here on the Artima forums. Quote (Leo Lipelis):

JSF multi-rendering capability — it’s an API bloat the weight of which you feel when designing custom components. Whether a project will benefit from multi-rendering or not is questionable. Why should I pay the price in terms of conceptual complexity of an API when I may not even need to use it in 99.9% of the use cases?

[2007-05-23] Six Things JSF Breaks (and How To Fix Them) – blog post by Josh Justice, title is self explanatory. Quote:

This is certainly no small list of challenges! JSF was built in a time when fewer client-side technologies were available, but it also seems to be targeted to projects that require less client-side interaction. If you are developing the next great web 2.0 application, you may want to consider a framework that intrudes less into the markup of the page, such as Struts or Spring.

[2007-05-25] JSF and real stuff – yet another laundry list of JSF problems outlined in this JavaLobby thread.

[2007-05-28] anti-JSF thoughts – blog post by Mert Can Akkan.

[2007-06-05] Re: Rod Johnson: “Java EE 6 Gets it Right” – in response to a comment I made on a TSS thread, Rod Johnson says this:

I still haven’t made up my mind about JSF, but we have people in our community who want to use Spring (and Spring Web Flow) and JSF, and it’s important that we accommodate that.

To put that quote in context, note that three years prior, Rod Johnson and Juergen Hoeller (Spring Framework #1 and #2) had this to say about JSF on page 408 of the book “Expert One-on-One J2EE Development without EJB” [2004, Wiley]:

Java Server Faces has been hyped as the next big thing in J2EE web development for more than two years and is now taking shape. In its current incarnation, JSF is a JSP centric affair that is heavily targeted toward GUI builder tools, resulting in code that gathers all sorts of concerns in the web page. There is no notion of view-agnostic controller and model, and no concept of pluggable views. With this programming model, JSF is well-suited for attracting .NET and other RAD developers, but not for becoming the de-facto standard web MVC framework in the Java world.

We expect to see a massive vendor marketing push behind JSF. However, we are not convinced that JSF will represent a real advance on existing open source solutions such as Tapestry, WebWork, and Spring web MVC.

[2007-06-07] c:forEach vs ui:repeat in Facelets – blog post by Roger Keays. Facelets is supposed to rescue JSF from JSP but it is not without its share of quirks !

[2007-06-11] the death of reason, professional addition – yet another blog post that suggests JSF is guilty of driving a fair number of developers away from Java. Quote:

i’ve been in a JSF class this week that has only reinforced my opinion that java web development sucks. it’s an over-engineered amalgam of crud. what i’m noticing, too, is that JSF is way behind the curve on annotations-is-the-new-xml java craze. this class has more than doubled my appreciation of ASP.NET.

[2007-06-27] Prefer RIFE,Stripes,Wicket to JSF – blog post by Frederic Daoud. Quote:

I recently worked on a professional project with JSF and ran into several problems. Don’t think I didn’t try “extras”: Facelets, Seam, … In the end it just piles on complexity without solving the problems, or solving them but introducing new ones.

[2007-09-07] Re: Java’s Fear of Commitment – O’Reilly / OnJava.com article by Robert Cooper. Quote:

I think JSF blows chunks.

I think Seam blows chunks squared.

While I can appreciate the design ideals of component based development on the web, each of these technologies, and especially stacked, represent an abstraction above and beyond what HTTP really is that makes me sick to my stomach to think about.

[2007-10-25] JSF Today: Standards versus OSS – blog post by Bruno Borges. Quote:

JSF 1.2 (JSR 252) is targeted for JavaEE 5.0. And I don’t even see JEE 4 in every customer I go, just like JSE 5, so try to imagine when JSF 1.2 will be world wide deployed. Again, standards are cool, but they lose speed. This spec was delivered at December, 19, 2006 and alternatives like Tapestry, Echo and others, including Wicket, are improving faster than JSF since that time.

[2007-10-27] JSF First Impressions – blog post by Keith. Quote:

[...] with JSF — you’re farther away from the final HTML. Its the components you include on the page that generate DIV tags and so forth. Having accrued 10+ years experience working with HTML, I find this the most frustrating aspect of JSF.

[2007-10-30] Xebia Web Framework Contest – a contest where different teams had to develop the same application using different Java web-frameworks. The team using JSF really suffered. Some follow up discussion here on Matt Raible’s blog. Quote: (‘Google translated’ from French):

JSF is clearly not the most productive framework, at least not on a day because the entry cost is heavy. And even once used to the framework, one may wonder how to be productive without error recovery and ask what limits the buffer management in the framework of a real project?

[2007-11-22] I’m a nerd. Or do I mean geek? [...] – blog post by Noah Sloan. Quote:

The problem with all that is that the JSF Ajax implementations suck. And the learning curve for JSF (much less components) sucks. It’s just too quirky. Hopefully JSF 2.0 will make component creation easy, enable RESTful services, and will make it easier for newbies and old hands to just get things done. I’d like to hope all of that, but the only positive things I tend to hear about 2.0 are from Ed Burns, who seems like a very nice guy, but whose rhetoric reeks of corporate “gotta toe the line/I think my company is the best ever [...]“

[2007-12-26] JSF 2.0 Faces Disjointed Components – SD Times article on how the “next version of JavaServer Faces aims to reduce configuration headaches”. Quote:

Sometimes, the cure for one’s woes is a hard look in the mirror. JavaServer Faces is facing up to its own configuration problems with JSR 314, the specification for JSF 2.0

[2008-01-04] Nobody Uses JavaServer Faces – blog post by Matt Long. Quote:

The bottom line is I’ve done a lot of web applications in my career, and I would *never in a million years* choose JSF to build a web app. It’s nearly unusable. Don’t get me wrong. I am getting the project done, but that’s a testimony to my own development skills, not how great the technology is. JSF stinks.

[2008-01-11] A Year of Wicket – blog post by Julian Sinai who evaluated web technologies and chose Wicket over JSF and other contenders like Tapestry. Quote:

I also took a close look at JSF. It seemed overly complex to me, and not much of a departure from the Struts era. It came across as a technology designed by committee, with the combination of several complementary libraries required to get the job done, and there are still too many configuration files.

[2008-01-28] Choosing a Java Web Framework – blog post by Ryan Sonnek. Quote:

Considerable ramp up time and tool support is a requirement to be productive. Instead of just working with standard Java and HTML, you end up locking into a particular toolset. The tools get you up and running very quickly, but you pay for the convenience since you can only build what the tool supports and they restrict how much you can do with the internal framework.

[2008-03-02] [OT] JSF vs. WebObjects – thread on Apple mailing lists. Quote:

As a final word i’d say that I won’t choose JSF for new project, i’d rather choose other frameworks like wicket or tapestry which are far more mature.

[2008-04-01] Thoughts on Java web frameworks and RIA – blog post by Sanjiv Jivan, creator of GWT-Ext and SmartGWT. Quote:

I’ve said this before that I feel that JSF is an incarnation of EJB 1.x which is overengineered and too focused on “enterprise patterns” making the simple things not so simple to implement.

[2008-04-10] JSF: A Wish List – Java Developer Journal article by Shay Shmeltzer. Quote:

Since the JSF specification doesn’t include a definition of how AJAX should be incorporated into the JSF lifecycle, each vendor/framework has its own approach to handling AJAX events, usually involving extending the JSF lifecycle. The result is that developers end up with one set of components that collides with the architecture of another set because they have different lifecycles. This must be addressed in the next release of JSF.

[2008-04-28] JSF2 – wiki page maintained at the Seam web-site on all the stuff in JSF 1.X that needs fixing in 2.0. It is painfully clear from this list how much of a raw deal JSF 1.X is. And *another* page of things to be fixed in JSF2.1 exists! Look for it somewhere below.

[2008-05-03] Game Over Java Server Faces – this was a great rant that suddenly does not seem to exist on the web anymore – so I’ve linked to the DZone entry for now. If anyone knows where this blog post can be found now – do let me know!

[2008-05-14] Developing long term strategies for using Java EE technology – a very telling quote from this IBM DeveloperWorks article goes like this:

JSF is still a relatively new technology. JSF is undergoing a major revision for the next round of specifications with an expected integration between JSF managed beans and Enterprise JavaBeans™. The risk of changes affecting existing applications will be higher here than with other presentation technologies. IBM does have representation on the JSF expert group and will keep a watchful eye out for problems.

One area of future concern is be how well Ajax support in JSF will follow the specifications for the OpenAjax Alliance. Through its participation, IBM will try to ensure that compatibility is maintained as the standards move forward. Ajax support in JSF will be new (when it appears) and use of that feature will be at a somewhat higher risk than other parts of JSF. More details will be known in early 2009.

[2008-05-14] JSF Issues – blog post by Phill. Quote:

Although JSF does make some development quicker, the amount of time you lose to stupid problems like this probably negates any gains you made originally.

[2008-05-29] At RailsConf 2008 [new] – I think the commenter that submitted this link (Ignacio Coloma) says it best:

I love the part where Craig McClanahan pulls JSF out of a hat, throws it to the crowd, then moves on to develop Rails applications.

[2008-06-06] Has anyone noticed? JSF components are hard even when they are easy… – blog post by Jesse Sightler. Quote:

Ever since I’ve had the experience of using ASP.Net and comparing it to JSF, I’ve been hoping that someone would come up with a way to improve the sorry state of affairs that is JSF component creation. Far too much time is spent on complex components and supporting a billion renderkits, when most of the time, I just want to be able to composite a couple of preexisting controls.

[2008-07-10] Seam, a second look at JSF – blog post by Petrik de Heus. Quote:

I actually forgot how much JSF sucked (I remember it was hard to test). The biggest problem is that it’s been developed by someone who doesn’t use it to write real applications. It’s full of crappy implementations of concepts that seem like a good idea from an ivory tower.

[2008-07-11] Java Frameworks – JSF vs Wicket, etc – discussion on Ars Technica forums. Quote:

No, you aren’t missing anything. JSF sucks huge monkey balls. The worst part is the convoluted, and heavy-weight response life-cycle. When it works, everything is wonderful and magic. When it doesn’t work, good luck figuring out why.

[2008-07-25] Wonderful Wicket – blog post by Sergey Grigoriev. Quote:

After I had read a book on JSF, I had impression that JSF is overcomplicated technology. Nevertheless I downloaded the latest release of ICEFaces and tried to write a simple “hello world” application with a singe button and a message area. I’ve spent two hours configuring it and six hours figuring out how to eliminate an exception.

[2008-08-25] JSF: The Good, the Bad, and Yes, the Ugly – article by Rob Williams. Quote:

In the most recent JSF tour, we were doing a wizard and had to bind to checkboxes. That turned into a nightmare, and for all the typical JSF reasons. JSF gets a low grade for heuristics (intuition is rarely the road to figuring things out).

[2008-08-31] A rant on Java standards – blog post by Jose Noheda. Quote:

How can something like JSF be promoted to be the standard? A component framework that lacks even one interesting component! That relies on third party libraries (many OSS) that are, of course, incompatible between them. Each one with a different AJAX approach (as the specification says nothing on the topic). And, worst of all, incompatible with JSP/JSTL and portlet development.

[2008-09-22] Fundamental Failing of JSF, Some Ideas for Overcoming – blog post by Rob Williams.

[2008-09-25] More Suggestions for Suturing JSF Breach – blog post by Rob Williams.

[2008-10-04] Web Framework Project Comparison Matrix – quote:

Users say, JSF “is the EJB of web frameworks. Cool in theory. Hell in practice.”

[2008-10-26] JSF is Not Fixable – blog post by Subbu Allamaraju, author of “RESTful Web Services Cookbook“.

I have not read the latest JSF 2.0 draft thoroughly, but upon a quick reading of all the changes, I don’t see anything to address the basic web usage. Unless there are more changes coming that will magically fix the core without an overhaul, JSF should the follow JAX-RPC into the JSR-graveyard.

[2008-11-03] “Simple” JSF 2.0 Component vs. Tapestry – article by Howard Lewis Ship. Yes, even in the not-yet-final JSF 2.0 custom component creation leaves much to be desired. Hope this answers JSF apologists who would complain about the above list of links claiming that it is outdated and that JSF 2.0 fixes everything etc.

[2008-12-18] JSF with a Web Designer

We’ve done only the first page of our application, and I’m really wondering if we took the right library. I believe now that in case you have a web designer in your team, you shouldn’t use libraries that generate HTML for you, like JSF or gwt, but instead use a framework allowing to generate the precise HTML the designer wants

[2009-01-14] Seam / JSF vs Wicket: performance comparison – performance and memory usage comparison of Seam / JSF vs Wicket by Peter Thomas. Quote:

I think we can safely blame JSF for the lion’s share of memory usage [...]

[2009-02-09] The Web Framework Evaluation – Part 03 – article by Sebastian Hennebrueder. Quote:

Do you understand the JSF request phases? On a first look they look simple but in fact it is a nightmare of things happening and being dependent on each other. It is not at all easily to hook in and change the behavior.

You like JSF and you are not convinced? Then try to write a library which caches a part of your component tree to render the page faster and make sure that it works with GET and PUT requests. You will have fun, believe me.

[2009-02-15] Un-Documented JSF: Reference – community contributed list of JSF “gotchas”.

[2009-02-25] JSF 2.1 – similar to the “JSF 2″ page mentioned earlier, another page on the Seam wiki details stuff that needs to be fixed in JSF 2.1 – perhaps these are things that did not make it into 2.0 ?

[2009-04-29] Shale in the Attic – the project that Craig McClanahan (spec lead of JSF 1) started as a supplement to JSF goes “where other projects go to die”. Also see the link dated 2008-05-29 for more background. Quote:

What happened? The answer is quite simple: Craig lost interest and left the community.

[2009-05-01] JSF: Suggestion for Performance Improvement – blog post by Nicholas Hagen expressing concerns with performance implications of JSF state saving.

[2009-05-11] JSF Nonsenses – Matthias Hryniszak starts an entire blog at http://ihatejsf.com dedicated to documenting his struggles with JSF. In his first post, he says:

Welcome to this new place in virtual space where you can express your darkest feelings about the sole nature of JSF (Java Server Faces) and other technologies that are connected to it (Facelets, JSF libraries and the like).

This blog has arose from the need to express my personal dislike for that glorious set of utilities that have made my life a misery.

[2009-05-12] JSF 2 fu, Part 1: Streamline Web application development – IBM developerworks article on the spanking new JSF 2.0. In the beginning of the article, David Geary (JSF EG member) admits that JSF 1.0 wasn’t that great. It is worth mentioning that JSF 2.0 is still not yet approved at the time of this blog post! Quote:

JSF 1 was developed in an ivory tower, and the results, arguably, were less than spectacular.

[2009-05-15] JSF Sucks (Compendium of JSF rants/reviews) – link to this blog post on DZone where there is some active discussion and also do consider voting up this link! The number and ratio of upvotes speaks for itself.

[2009-05-15] Reasons why not use JSF – someone posted a link to this blog post on the Seam forums, some discussion there. Look out for the comments from Francisco Peredo, for example this one.

[2009-05-16] “JSF sucks” on Reddit – wow, that brought a lot of traffic! Some good discussion there as well.

Update 1:

[2009-07-27] U, I and JSF – still painful after all these years – detailed article by Karl Banke. His conclusion:

[..] it is not a proper component framework, let alone a complete one. It is intrinsically over engineered, yet critically underspecified. As such, it can serve as a powerful basis for a real component framework. Because of the critical parts missing it is essentially impossible to mix JSF components from various providers without including a lot of overhead and loosing a lot of consistency. Frameworks like JSF should essentially make easy things easy and hard things possible. Yet JSF’s standard components, even in JSF 2.0, fail to deliver basic One-O-One web application features from 10 years ago. It is a remarkably complex specification that delivers pretty much nothing out of the box.

[2009-11-10] JSF 2 – evaluation and test – very detailed evaluation of the brand new JSF 2.0 reference implementation (Mojarra) by Sebastian Hennebrueder and Holger Brade. Sebastian’s conclusion:

JSF looks like an old castle, where every generation added pieces, towers and buildings. I don’t blame the developers for this, as the code shows, that they know how to do a proper job. I believe that the reason for the current status of JSF is that the features are defined by a specification. The specification is industry driven with a focus on being backward compatible instead of being technology driven. Everything works somehow but always rather complex than simple. Every release makes it worse as nothing is dropped. I am sorry, but I can only see a bad ending for such a strategy.

Pages are extremely verbose. Using it make you feel being unproductive most of the time. JSF 2 brings some innovation but in a lot of areas it doesn’t even catch up with the current status of other frameworks. It is likely to be outdated before it is actually stable.

I wouldn’t use it for new projects and especially not for large enterprise projects.

[2010-01-29] What’s new in Alfresco Enterprise 3.2? – some insights into why popular open-source ECM vendor Alfresco is dropping JSF in favor of a more Web 2.0 oriented approach:

Alfresco has been fairly open with the fact that their ‘Explorer’ client which is based on JSF technology is no longer being actively developed. While JSF is still around and actively used at a lot of places, it is a ‘heavier’ technology compared to a lot of whiz-bang Web 2.0 stuff. Alfresco is now investing development cycles in Alfresco Share.

Update 2:

[2010-09-09] RichFaces 4.0.0 Release Plan Updated – the long awaited release of RichFaces 4.0 final (which is supposed to support JSF 2.0) is further delayed to Feb 2011 because of “issues in the JSF specification”. Note that as of September 2010, only ONE production ready JSF 2.0 component library exists. The JSF 2.0 spec was approved well over a year back (May 2009) and was available in a draft form much earlier as is typical in the JCP.

We had hoped to get the final release of 4.0 out before the end of the year, but as mentioned previously we have run into various hurdles: These include identifying issues in the JSF 2 specification, and implementations (JSF RI, MyFaces).

[2010-10-16] RE: Moving from Spring to Java EE 6: The Age of Frameworks is Over – Matt Raible’s observations on “standards” vs frameworks:

Another reason I don’t like JSF: there’s very few developers in the wild happy with it. The major promoters of JSF are book authors, trainers, Java EE Vendors and MyFaces developers. Whenever I speak at conferences, I ask folks to raise their hands for the various web frameworks they’re using. I always ask the JSF users to keep their hands up if they like it. Rarely do they stay up.

Update 3:

[2010-10-22] Java EE, Spring, and why I care – a rant on Java EE vendor FUD by Papick G. Taboada:

Take a look at JSF. JSF is obligatory part of a full stack application server, but JSF gives you nothing. Again, you have a component model, and each vendor will provide the required runtime API. But you won‘t be happy with that, you will need a JSF library like RichFaces, ICEFaces, PrimeFaces, MyFaces, etc.
Take a good look at those. You will realize that, once you start using JSF, you are not standard anymore, you are bound to the JSF library vendor. The programming models for the components are different, the tags have different name. Switching or mixing JSF library ranges from very hard to impossible. So what good is the JSF standard for? Why is RichFaces for JSF 2.0 taking so long and how many people are developing it? Will it be there tomorrow? Will it be continued? JSF surely, but RichFaces, ICEFaces? Who can assure that?

[2010-10-26] JSF Expert Group Disbanded With No Successor JSR – pretty damning when folks outside of Sun / Oracle who have been trying heroically to fix JSF and rally the community – say that they have almost given up. If you thought that the JSF spec would get any better in terms of reducing the need for vendor-specific and proprietary extensions, think again.

According to Balunas, the expert group was still very active in their communication and development, and he doesn’t believe that dissolution of the group was necessary. He says that it will now be “very difficult” to continue supporting the Java Server Faces specification without an official JSF and EG in the JCP, mainly because there are no longer intellectual property and governance guarantees involved in JSF development if there is no current or successor JSR for JSF.

Update 4:

[2010-11-18] “I hate JSF with a passion” – James Gosling speaking at a Silicon Valley JUG event, skip to 47 minutes into the video below or use this direct link: http://www.youtube.com/watch?v=9ei-rbULWoA#t=47m

I hate JSF with a passion. And JSF was done, you know, there are a few things that were done for, I don’t know whether they were stupid reasons, they’re just, it’s just the way the world is, so, Microsoft had this thing called ASF which was angle brackets and percent signs with BASIC code there, then they are [gestures] “in-between”, right, and they go on a marketing campaign saying, “this is the greatest thing since sliced bread”, they get all the journalists to go, “ohh, that’s the greatest thing since sliced bread”, they come to us and they say, “ooh, angle brackets and percent signs and code in between, isn’t that the greatest thing since sliced bread?” What’s your answer to that? And if your answer is “that’s stupid – you know, there’s a better way to do that”, the press by and large can’t parse your sentences. And so we did do JSF as basically a clone to ASF just because it was easier to explain to the press. And then it wouldn’t die.

Seam / JSF vs Wicket: performance comparison

A while after Seam support for Apache Wicket was announced, I downloaded Seam and took a look at the Wicket example. Then an idea struck – how about doing a performance comparison – I mean, here was the very same application implemented in JSF and Wicket – right? So I decided to write a JMeter script for both the JSF and Wicket versions of the Seam “hotel booking” example and compare results. I started right away but very soon got tired of waiting for app-server re-starts on my trusty laptop (Jetty has really spoiled me) – and it kind of bothered me that the Seam examples were not in Maven 2 layout. Anyway, at some point I decided to re-write an “EJB-free” version of the Seam booking example using just Wicket and JPA. And use Maven and Jetty. And… one thing led to another – and what I ended up doing is this:

  • Adapted the Seam JPA example (the one that does not use EJB) as the baseline application. Converted it into a Maven 2 WAR project which can run on Jetty.
  • Implemented what I hope is the exact equivalent of the above using only Wicket and JPA, also Maven-ized and Jetty-fied. Decided to also experiment with some of the ideas in this blog post.
  • Wrote a JMeter script for both applications taking care to exercise identical functionality.
  • Used an Ant script to run the JMeter scripts in batch mode (passing number of concurrent users as a parameter) and start / stop Jetty in sync.
  • Automated the entire cycle of running the load test for 1, 5, 10, 15 and 20 concurrent users including some code to parse the JMeter logs and generate a CSV file of tabular results.
  • Also included an Ant target that takes a JVM heap dump at the end of the load test – just before the users are logged out and the HTTP sessions killed.

I was able to re-use the official Seam Wicket example to some extent, mainly the HTML files – but the Java side is almost completely re-written. The Seam booking example covers quite a bit of ground from the framework comparison point of view – for example:

  • Security – some pages are secured and redirect to a login page
  • Templating – some pages inherit from a common layout with a header / footer defined
  • Ajax
    • hotel search results refresh as you type and a “busy” image is shown during the Ajax request
    • form field validations occur as soon as the field loses focus
  • Session scope – some state is stored and retrieved in the session
  • Page navigation / state
    • user navigation state transparently managed by the framework
    • user should be able to work in multiple concurrent conversations (browser tabs)
    • the browser back button should work as expected
  • JPA – getting access to the entity manager and transaction management
  • Forms – binding, validation and displaying error / info feedback to the user
  • Hibernate Validator – annotations on the JPA entity classes are re-used for form-validation

Both sides use the exact same entities, persistence.xml and initial HSQLDB import. I’m using the latest Seam 2.1.1-GA and Wicket 1.3.5. Disclaimer: my Wicket code may not be ideal, and I’ve also experimented with a custom RequestCycle for JPA and tried to use inherited models as far as possible. Instructions on how you can download the source and run the scripts on your local machine are at the end of this blog post.

I may do some follow up blog posts on how the code compares between the Seam / JSF and Wicket implementations, and also share some tips on writing JMeter scripts and automation using Jetty, Ant etc. I’m also expecting to have to make corrections and changes to the code based on feedback. For now, I’ll summarize my observations on performance and memory usage.

In the JMeter script, except for the login and logout (first two rows and last row), the actions are executed in a loop ten times for each concurrent user. So if the number of concurrent users is 20, the login and logout actions happen 20 times and the rest 20 x 10 times. The numbers below are average page response time in milliseconds.


Wicket appears to be faster by a wide margin. For two pages (“ajax post search” and “post confirm booking”) the results are a bit closer. This can possibly be explained by the fact that these particular actions display the results from a relatively expensive database query. My amateur profiling attempts suggest that the database query is taking most of the time here.

One thing I have to mention: the “cc number” and “cc name” requests are simulations of the Ajax validations of the credit card number and name fields on the booking form. For these particular requests on the JSF side, the entire form is being POST-ed instead of just the value of the form field being validated when the user tabs out (onblur). So the difference here is quite dramatic. I did try adding ajaxSingle=”true” in the JSF view but it did not appear to work (I used HttpFox while building the JMeter scripts). I can re-post the updated results if someone lets me know what changes need to be made to “book.xhtml” to get the Ajax validation to work as expected.

Memory Usage:
The JMeter script can be told to skip the logout page and I wired up one of the Ant targets to take a JVM heap dump / snapshot as soon as the JMeter script completes. So I can compare what the heap looks like just after a load test when all the concurrent HTTP sessions are alive.

I’m very much a NetBeans user but I have to say that the Eclipse Memory Analyzer is far better than what the built-in NetBeans Profiler offers for looking at JVM heap dumps. Here are some side-by-side screenshots of the heap analysis after running the JMeter script for 20 concurrent users.

“Top Consumers” report below showing the classes that dominate memory usage:


The “dominator tree” report below is very useful to see which objects hold on to the most memory directly as well as indirectly. The column headings after “Class name” are Shallow Heap, Retained Heap and Percentage. Shallow Heap means the memory consumed by a single object and Retained Heap is the sum of shallow sizes of all objects that will be garbage collected if the given object is garbage collected.


Looking at the above two reports we can infer that on the Seam / JSF side, the 20 sessions each take up about 800 KB adding up to around 16 MB total. On the Wicket side the 20 sessions add up to around 1.5 MB. On the Wicket side it is the DiskPageStore that appears to hold the most memory and we can see what is going on here after drilling down a little:


The Wicket DiskPageStore uses SoftReference-s to serialized pages so the memory will be reclaimed by the JVM if needed. And the SerializedPageWithSession holds a WeakReference to the actual page instance (MainPage). You can also spot the byte-array which is the result of page serialization. If a serialized page is requested (perhaps the user hit the browser back-button) and the page is no longer in memory because the SoftReference has been GC-ed – it will be restored from the temp file that the DiskPageStore has been saving pages to.

I’m totally impressed by the Eclipse Memory Analyzer. Here we can see the break-up of the contents of the largest HTTP session on both sides. I think we can safely blame JSF for the lion’s share of memory usage on the left:


Finally, a summary of the heap-dump comparison (for 20 users) collated from the various reports:




  • JDK 1.5 or greater installed
  • Apache Ant installed
  • JMeter 2.X available unzipped somewhere (better use latest 2.3.2)


  • Do a Subversion check out of the source from here: http://perfbench.googlecode.com/svn/trunk/perfbench/
  • Create a perfbench/build.properties file that points to your JMeter installation. You can look at the comment in perfbench/build.xml for an example.
  • Open a command prompt, change directory to perfbench/seam-jpa
  • If running for the first time, use the command “ant jmeter-cycle”. The build script would prompt for the number of threads, so enter “1”. It may take time for all the required JAR files to get downloaded. Once you see Jetty start and stop successfully, you should be all set to run the actual benchmark.
  • To start the benchmark run “ant jmeter-cycle-full”. This should take 2 – 3 minutes to run a series of tests for 1, 5, 10, 15 and 20 concurrent users. Results will be dumped into perfbench/target. You can look at the *.csv file at the end for the results.
  • You can also run a load test which saves a snapshot of the heap dump towards the end by running “ant jmeter-cycle-heapdump”.
  • Repeat the previous 3 steps after changing working directory to perfbench/wicket-jpa

Update: perfbench/build.xml starts Jetty with JVM options “-Xms64m -Xmx64m” and you may need to change this if you want to experiment with more concurrent users.


Get every new post delivered to your Inbox.

Join 29 other followers