JSF I love you… me neither

the Pilori

Is it the best tool to talk technology ?

This post was first published in french on Ippon Technologies Blog. This version was automatically translated.

There are certain technologies that trigger passions. They contain within them the potential to polarize opinions and leave little moderate or indifferent about their people . They sometimes go to start wars of religion (we combat that can be ) in which ship some IT consultants .

JSF is certainly part of this small group of tools or frameworks dedicated to public obloquy by one or extolled by others.

As to admit right away, I’m pretty pro- JSF , while trying to maintain some objectivity in his place . Although this technology has made me suffer a lot when I started using it in 2005, it has me both times pleasantly surprised or thrown into the depths of frustration to others. Suffice to say that I kept oscillating between love and hate relationship with JSF .

However, I recently started a project with JSF 2 and I must admit , at the risk of chip equanimity that I like to show : ” JSF 2 really rocks”.

Live my life with JSF – a feedback

I started getting interested in JSF in 2004. Exclusively based web developments , my stack was then composed of Spring 1.0.1 , Struts 1.2 and iBatis 2 . Struts I liked but I found that I was missing something to enrich my user interfaces. Of course , I used Apache Jakarta taglibs for JSP tag libraries a bit more substantial and developed myself, but it was still generally weak . So I started to explore JSF during the second half of 2004 in parallel with my projects and had the opportunity to put this knowledge into practice in 2005 with JSF 1.1 on a beautiful project . As to admit the transition from theory to practice proved to be a cold shower : the technology as it is, out of the box was almost unusable for a real GUI development with HTML . And at the same time, some aspects of the technology were quite magical as that allowed listeners to respond to events on the interface or system conversion and validation although a bit heavy was well designed .

This first project was for me a lesson in frustration punctuated by : “it works almost ” or ” bad, it was the powerful air but is unusable .” I can still deliver my app ( I would clearly planted me if I had to deal with graphic designers and web designers ) and my customer , satisfied, command me one second repeating and extending certain features of the first. There, I have a big doubt is that I leave 0 with something more classic? Or do I persist in trying to find how to fill the missing 5% to techno to make it productive features? Having enough time off , I take the party to explore the second track by telling me that if I can not find anything , I still have time to start from scratch. It is at this point that I discovered (thanks to all the developers who have suffered before me) the Facelets project is the first glimmer of hope in the desert of frustration that was JSF . Facelets lifting the brake templating makes it usable without the straitjacket and wall upholstery technology. I book this second project much more calmly than the first, even if everything is not perfect .

At that time (early 2007), the 1.2 version of JSF is out and officially part of Java EE 5 , I meet many small projects , but have not had a flawless experience with JSF , I leave the techno side until I fall in JBoss Seam. And then I find sesame. Seam JSF finally unlocks and makes it elegant and productive in filling gaps and correcting defects. After many small projects and especially two big conducted with the framework , I can say that this is one of the most productive mixtures Java eco system.

Pre balance JSF 2: JSF is great when added techno Facelets templating and Seam framework without forgetting a good library of components such as RichFaces , Icefaces or Primefaces . That’s a lot of things to learn and master a simple GUI for techno. And what about a standard technology to rely on solutions , although Open Source, but owners to be usable ?

But it seems that others felt like me, because, as if by magic, all these faults were erased with version 2 of JSF . Facelets is now an integral part of the specification and inputs for Seam JSF were integrated. But I will return later.

Why so much hate ?

I think I have already given an initial answer to this question in the previous paragraph . Beyond empirical and personal feeling , it seems interesting to me to synthesize some primary anathemas of all ” Hate Boys” who fed the headings ” JSF sucks” that is found in almost all of the sites linked to Java ( I do not put a link on these sites so as not to contribute to their pagerank ) . Some of these criticisms were well founded , the other a little more a matter of personal discretion or bad faith .

Poor bets on the evolution of the Web

Keep in mind that the beginning of the JSF design dates back to 2001 and at this time there, it was quite difficult to imagine the Web as it is today . It is a time when the java applet is always a viable solution customer and where javascript is only a second technology area which is delegated to the best verification form fields .

People working on the first JSF specification , so have clearly missed the developments REST and Ajax Web obsessed they were to make a Swing for internet. This leads to two major fault

The use of technology ignoring HTML templating

There, nothing to say. This is a mistake that cost to the reputation of JSF . Technology templating default JSF 1.x is based on JSP and only accepts tags (JSF tag f : verbatim royally allows you to embed HTML in JSF , but nothing to integrate JSF components in the HTML) . The arrival of Facelets and the possibility of changing technology in JSF templating corrected this huge gap. But a little amateur side of Facelets project and the lack of official support of the Expert Group JSF Facelets that have long remained confidential source or question the sustainability of the mixture.

activation JSF life cycle only from a HTTP POST .

Another blunder design : consider only the HTTP POST can be the starting point of a complete server-side processing . I go back a little further on the JSF life cycle , but basically , it needs to be enabled for the server part is requested. This limitation in addition to unnecessarily complicate developments had disastrous side effects to the reputation of the framework. It followed the inability to have bookmarkables URL for example, or the inability to respond elegantly to the solicitation of a secure url ( the junction between any part servlet/jsp and JSF part ENTAILED large seams in apps with the obligation to have recourse to bad practices ) .

Many third-party solution ( Seam head ) provided a solution to this huge gap. Again, the versatility of JSF helped make these corrections elegantly and naturally grafting extensions at the points provided in the specification. However, to use one of these solutions often was to fall on a proprietary technology that was not always compatible with library extensions or other third-party components .


Between 2001 and 2004, a period of JSF design , the concept of asynchronous communication between the browser and the server is still an eccentricity that no one ( from Google ) really seriously considering . This is the golden age of CORBA and IIOP and few people consider that the web becomes a rich application platform . We can therefore not too blame JSF Expert Group for not anticipate this need by limiting the specification to only commands POST and GET for a little chat between client and server.

However , this lack had to be filled by others of varied ways making various component libraries making Ajax totally incompatible with each other .

ecosystem frustration

Very soon many publishers have grabbed JSF component libraries offer . Just go take a look at JSF matrix to realize that this technology has inspired many people. This aspect could have played for JSF , but unfortunately the limitations or shortcomings mentioned above have severely fragmented eco- system : each publisher providing its own solutions to address these shortcomings, the various component libraries have become very quickly incompatible ENTERED them. Thus, the JSF specification has resulted in fragmentation and the creation of parallel Framework components such as ADF Faces or Faces Ice or to a lesser extent Rich Faces . The value of technology becomes therefore very high , since it was possible to mount a real ecosystem.

The JSF life cycle

To end on a positive note , I’d pick up on much unjustified criticism encountered in JSF critics . Central to these criticisms, the JSF life cycle . These criticisms might be generally entitled: ” I do not like JSF , because it does what I want,” are quite similar to those that you come across on another technology built around a cycle life Maven . I find that most developers prefer to adapt technology to what they know rather than learn and see if their standard operating suits their needs .

Indeed, the JSF life cycle is central to the technology and ignore what is clearly courting many crippling problems. JSF does not offer shortcuts or hacks kind scriptlet to make the learning economy technology. However, if the life cycle is essential , it offers numerous extension points. It is thanks to this extensibility that JSF has been saved : the development of the various workarounds have taken advantage of this extensibility to provide stylish add- ons to JSF 1.


JSF has often been criticized for its “bad” performance. Without going to say this is a great warrior , I think a lot of false things have been written on the subject and that the problems of slow JSF are often due to poor knowledge of the framework ( life cycle and functioning of some components) . Debate on these issues is not the purpose of this articles, however, I refer you to this very interesting article by Dan Allen optimization in a datatable/Seam JSF support which shows that leaning on the subject , we can divide the response time by 10.

JSF anyway

After the indictment to final -stage , you are right to ask why I did not put in the trash JSF as many have done long ago. Beyond a mere stubbornness, I have good reasons for sticking with this technology.


The size of the community around JSF is simply huge . It is quite difficult to realize because in France , this technology is rather marginalized in favor of Struts and Spring MVC with JSP so a follower of JSF sometimes feels lonely as a fan Daniel Guichard lost in a Rammstein concert .

However, simply go online to see the specialized sites and blogs abound on JSF . Mention may be made quickly JSF Central or JSF Tutorials or all website publishers component library you will find on JSF Matrix . This community is rather enthusiastic and constructive . It also organizes many around major JSF component libraries as ICEfaces ( one of the first HMI solution for full Java Ajax, released in 2005 ) , RichFaces or most recent but highly effective PrimeFaces . Until the arrival of the JSF 2.0 community were fairly tight as choose a library made ​​it almost impossible to use the components of another . Last year these communities open to each other , enriching even more eco- system.

gold in the mud

Reading the beginning of this article might suggest that JSF is a technology permanently disabled at birth. In fact what saved this technology is that its core is extremely well thought out and super configurable . This core is used to change the rendering technology to intervene in the life cycle of applications or changing technology for binding server-side objects. What sealed JSF is that the defaults configuration techno were clearly wrong or incomplete. Third-party solutions around JSF is the best demonstration of this intrinsic quality of the specification : they all naturally graft technology to complement or compensate for deficient parties. ICEfaces which is totally appropriate life cycle of JSF or Seam 2.X which adds to erase all its faults perfectly illustrate this opening in technology.

Of course , who quickly passes next to techno or who suffered without understanding only retain the muddy layer , but it was enough to dig to see the gold inside .

The components/event “standard” solution

Yes, I know : ” we should not choose a technology because it is standard ,” I know the chorus often rehashed by some developers who do not want to shake their habits. I generally agree with this, but I think you also do not refuse on principle because it is a technology standard . JSF is now a good standard and although this technology is not suitable for all needs , I think it is highly desirable that every web developer java application knows it would do to have a point of comparison with the technology used in their development.

For JSF ( like many Java EE technologies) the first interest to be a standard and have a specification is to have multiple implementations. JSF has two implementations: the reference for Oracle: Mojarra and the Apache : MyFaces . These two implementations are very good and allow developers to choose the most efficient engine for their project . Emulation which is born of the existence of these two projects is beneficial for everyone and if your implementation contains a bug that bothers you , you can always switch to the other ( it’s live ) .


I talk a lot of Seam, but this framework has brought a lot to Java EE . By providing a more modern approach to dependency injection and overcoming virtually all defects JSF 1.x , this framework serves as the missing link in the history of Java EE .

For more information on the topic you can still read The missed appointments of Spring returns to this point . Anyway, Seam creators have decided to contribute the majority of the framework in Java EE and make a specification (CDI) and improvements for JSF . These improvements , plus those of other members of the expert group JSF 2.0 vendors make this new specification a real success.

JSF 2.0: a new beginning

I will not do a detailed review of news and developments in JSF 2.0. Others have done much better than me (and I ‘ve already lost 80% of my readers with the length of my post) , so I recommend you series written by members of the Expert Group on JSF 2.0 Java Lobby articles . I just stay on the main aspects of these developments .

Standardization Facelets

I opened the ball with a non- novelty . The Facelets JSF 2 is more or less the one we used with JSF 1.X The great novelty is that it is now the default templating language JSF . About the benefits of Facelets the design and cutting of an interface and the division of roles between developers and HTML editors could embark a few dozen paragraphs I reserve another post . Still, that standardization stabilizes JSF and is the official recognition of the Expert Group ratage of templating in JSF 1.0
The real

get support and its consequences

Well, ok , ” get support “, you can sneer ( but not too much) . Again, this big hole in the racket JSF was filled long by third-party solutions ( I told you about Seam ?) , But then there it is you can write something like :

[ xml]

< f : viewParam name = ” orderid ” value = ” # { } commandHandler.orderId ”  required = “true”  requiredMessage = ” You shoulds Provide an order id”/>


and the parameters of the URL can now be recovered at the beginning of the page and treatment can be started right away. Treatment can optionally redirect to an error page in case of failure .


Ajax is finally part of JSF , it integrates natively life cycle and it is possible to invoke either javascript call is a JSF tag . The partial refresh views JSF is supported and supporting technologies such as advanced is included in and should MyFaces the Moraja be soon .

Facelets components

The development of JSF components was quite a tedious task in JSF 1. It becomes easier in JSF 2 thanks to the partial backup state but mainly because Facelets that creates a type of very simple components: composites. This is made ​​of pieces of views (pages) JSF highly customizable and reusable . This concept allows for example to create a jsf tag to include a flash applet or a jQuery effect to be repeated ( tooltip ) .

Intuitive and versatile , this approach already existed in earlier versions of facelets gives an appreciable flexibility in the design of interfaces and makes a real JSF technology ” Lego ” modular .

Improved interaction with the JSF life cycle

The JSF life cycle has not fundamentally changed since JSF 1. This changes a lot , these are the tools to interact with it . allows the tag to respond to an event occurring in a given phase ( as in Example recovery parameter given above ) . These events can also trigger JavaScript or Java code so much more natural than before calls. The life cycle becomes easier to adapt to specific needs which makes it even more versatile framework.

More exception handling is finally integrated ( Seam again) , and it is possible to switch automatically to an error JSP or JSF page in case of trouble in treatment.

Improved navigation and simplified

Improvement from Seam again. Conditional navigation rules allow more flexibility in navigation views and actions in JSF JSF tags can now be either views or destination of outcomes that will be addressed by the navigation process without having to go through the invocation code .

Conclusion : JSF 2 balanced mix of Web UI ?

In conclusion, I will discuss current approaches between antagonistic frameworks that promote the diy on the HMI part (Ruby on Rails, Play! , Spring MVC) and those that deliver rich components approaches very little control over the code product (GWT or Vaadin for example). These two perceptions have their pros and cons and I am not going to rule on the subject.

I simply note that JSF 2.0 is a solution that allows you to play both ways , allowing to develop reusable components or even a very simple way and/or to use very rich component libraries are high-level produce rich interfaces without you have to master HTML 5 , CSS3 and javascript.

For those who still wonder why JSF is the technology standard web GUI Java EE 6 , I think the answer is much flexibility in this and that, even if JSF still has progress to make , it has the merit of offer good equalization between the simple interface design and the creation of rich web client. An almost perfect synthesis of Java web frameworks somehow.