Rob Williams is a probabilistic Lean coder of Java and Objective-C. Rob is a DZone MVB and is not an employee of DZone and has posted 170 posts at DZone. You can read more from them at their website. View Full User Profile

Fundamental Failing of JSF, Some Ideas for Overcoming

  • submit to reddit

If you look at the history of technology, there are certain rules that exist in a kind of stratosphere, above specific technologies, that apply to lots of areas. One of those tablet rules has a vernacular version that is sh*t in/sh*t out. The basic idea being that if you let bad stuff into your program, your program will produce bad stuff. Of course, in the old days, the ‘bad‘ would be data. Today, in the age of object orientation, just calling it data is probably wrong, instead, it goes to the whole generative problem that my last couple posts have discussed: how do we create objects, where, and how are we sure that they are valid?

In a lot of ways, OO brings the issue into much clearer focus because the old days of SI/SO, we would just say ‘well you have to make sure the data is good‘ v. in OO we can say ‘our abstraction must be whole.‘ So in other words, whereas in SQL we would say ‘we must block the door by implementing some set of constraints on the various effected tables,‘ in OO, we can say ‘an Address (example) is not valid unless it has a postal code, city, state, and a number and street.‘

While I love the idea of binding, and see it as the correct way to do ui framework‘s, JSF‘s approach to binding leaves some things to be desired, but none is as dire as the fact that any domain object that is bound in JSF must implement sets and gets for all of the properties that the user wants to make writeable. Now, the reason this is a problem is because it basically says: ‘go ahead, pin the entity layer to the ui, and if you want to constraint what gets constructed, you must do it through the validation/conversion facilities in the framework.‘ This translates as: ‘make all columns take nulls and empties and just cross your fingers that THE most untestable part of your application will be sufficiently secured through the diligence of all those who would expose a property through an interface component.‘ This is not the contract model of Meyer (DbC), but it‘s also not even the defensive model of McConnell, it‘s a strange hinterland in between where the most important phase of the development process (the generative problem: the making of things/entities), is not even left to chance, it‘s granted almost no importance, and leaves us in a world where the transmission of DNA is so willy nilly that we quite literally spawn mutants, saying to ourselves that we will fill in the chains after birth.

My first instinct on overcoming this was to cast it as a PAC v. MVC problem. The main advantages of PAC over MVC are the fact that it sees the ‘model‘ as hierarchical, and it makes provisions for the various components to have their own model needs that are independent of the domain model that is being transformed through the use of the ui. But PAC also opens the door to the idea that those intermediary abstractions (the A in PAC) could be used to create complete domain objects AFTER the edit session. In JSF, when the form is instantiated, for instance, to take a User‘s Address, a bean is made of Address, with all the fields empty (e.g. Street, City, State, etc.) and editing is commenced. Of course, you can create a validator, but again, what you are saying is that you can make the entity as a mutant and just not let the user out of the post-create infusion phase until certain constraints are satisfied. Using the PAC approach, we would make a bean called AddressInputAbstraction and then we would take all the components, and that component would be a builder of sorts, because it would have a getAddress method on it. The trick being that the get method would use the static builder in Address and so if the address was invalid, it would never get created in the first place.

Then the question becomes do we just make these Abstraction classes for each entity and we write out the mappings in the get method (a single line of code, given the syntax of the static builders), or is there some way that we could provide automatic mapping? Of course, the problem with the automatic approach is that many of the properties are going to be primitives, so you would have to rely on names, which would be sketchy at best. Of course, if JSF were able to have different ways of doing binding (other than just interpreting the expression as a property name that has a corresponding set), this would not be a problem: we could just map the builder properties directly. Another option would be to use annotations to provide the wiring, with the idea that only builder methods that were not simple mappings of name/method name would require additional metadata.

Ultimately, you just have to ask yourself the question: were all the AT&T folks like Andrew Koening, and now Josh Bloch in the Java realm onto something when they became increasingly obsessed with immutability, or are you happy to just live in the wild west where anything can be born, cars without wheels, human beings without brains (ok, bad example), etc. The other advantage of the PAC approach is that you can lock the domain classes so there really is no way for people working on the ui to take shortcuts or remove the protections against birth defects.


Published at DZone with permission of Rob Williams, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


John Denver replied on Tue, 2008/09/23 - 8:55am

I read 2 times your article but is little bit confused and hard to read or understand your point. Anyway sorry to ask you this but what is your point heheh? PAC is better than MVC?.

Kito Mann replied on Tue, 2008/09/23 - 12:38pm

This hardly seems like a major failing of JSF to me. As someone who's also developed with Swing, Delphi, and ASP.NET, I find that binidng save a ton of time.

If you don't want to use bindings, you can just read the values directly from the control.

public String submit()
    Address address = new Address(streetInput.getValue(), cityInput.getValue(), ...);

This way you don't have to create any additional intermediary objects.

Kito D. Mann -- Author, JavaServer Faces in Action - JSF/Java EE consulting, training, and mentoring - JavaServer Faces FAQ, news, and info

* Sign up for the JSF Central newsletter! *

Mario León replied on Tue, 2008/09/23 - 1:08pm

As Kito says, it doesn't seems as a major fail to me, I agree with that the real problem is the creation of objects, but this post is not focused on the real problem.

As I understand from this post, this problems is present, for example, in spring, because it is possible to create the object, and you'll get an empty object, as said here, a "mutant".

I think the issue here is that when you define a domain object (aka model object), it's your responsability as a "professional engineer" to determine which would be the default state of a new object, this can be acomplished easily, by using the default constructor.

I have see a lot of programmers that doesn't make use of the default constructor, even when it's a best practice. If you have an object that has invalid states in its properties from the very beggining, it's not a problem of any framework (JSF, spring, ...) it's a problem of the definition of the object you did.

What do you think about it?

Marc Stock replied on Tue, 2008/09/23 - 4:56pm

JSF is an over-engineered piece of garbage. In an era where there are frameworks like Wicket, I cannot understand how anyone can even consider using JSF. In fact, imho, JSF is so bad as to make me think fondly of Struts. The fact that it's the second most popular Java web framework is simply mindboggling to me. It makes me question whether humanity will survive in the long term. If you need two additional frameworks on top of it just to make you not want to commit suicide, that should tell you something.

I would suggest picking a framework that isn't retarded instead of worrying about how to fix JSF.

Oh and for the record...I've actually written an app using JSF so I'm not an armchair quarterback pontificating how it might be if I had to code apps with it.

Kito Mann replied on Tue, 2008/09/23 - 5:39pm

@Marc: Maybe you should back up your opinion with some specific points. Or, better yet, actually say something about the article.

Kito D. Mann -- Author, JavaServer Faces in Action - JSF/Java EE consulting, training, and mentoring - JavaServer Faces FAQ, news, and info

* Sign up for the JSF Central newsletter! *


Marc Stock replied on Tue, 2008/09/23 - 7:32pm in response to: Kito Mann

Yes, because I'd like nothing better to do than argue endlessly about whether JSF sucks or not when I know damn well there's nothing I can say to change your mind given your a known JSF fanboy and you have a vested interest in its continuation. Is that unfair? Maybe, but I don't have time to go on endlessly about something most people already know.

Mario León replied on Wed, 2008/09/24 - 11:04am


I consider my self a JSF fanboy too, but I don't like to get blind by a pseudo-fanatic spirit.

I have worked with struts, struts2 and JSF, I like JSF, but I like struts2 as well, and in an article like this, I always try to be as objetive as possible, in order to provide a nice feedback, and avoid starting a flamewar.

Independently of your opinion about JSF, what do you think about the article, is the author rigth? is wrong?

I know JSF have some failures, it is not a perfect framework (but which one is perfect by the way?), but please, try to focus on the articles and the ideas exposed.

Bruce Fancher replied on Wed, 2008/09/24 - 11:59am

Coincidentally, today's Dilbert comic explains perfectly how JSF came into being:

Pointy-haired boss: Andy has been appointed our Director of Green.

Dilbert: Director of Green? How do you get a job like that?

Andy: You start by being the director of something else and screwing it up.

How did Craig Whatsisname get to be the tech lead for JSF? Simple, he wrote this Godawful framework called Struts that set Java web development back by at least five years and then somehow maneuvered his way into writing its replacement. It's bad enough that so many developers drank the koolaid and started using Struts, but what's really embarrassing is how few people learned their lesson the first time around. Fool me once . . .

This is usually the part where someone chimes in and says "well, maybe Struts wasn't the greatest thing ever, but that's all there was at the time!"

Um, no. There were plenty of alternatives, including WebObjects and Tapestry. You just didn't bother to find them.


Marc Stock replied on Wed, 2008/09/24 - 12:18pm in response to: Mario León

The author takes the most circuitous and complex route to explain the most simple thing. So in that sense, it's a poor article (but explains why he gravitated to JSF). He's right that there's a problem though. My recommendation is to move to a better architected framework where trivial issues such as this don't exist. The answer may be trite, but you can't put lipstick on a pig. (where have I heard that lately??)

I know JSF have some failures, it is not a perfect framework (but which one is perfect by the way?), but please, try to focus on the articles and the ideas exposed.

Yes, there's no perfect framework. In fact it's impossible to create such a beast for at least two big reasons: 1) the web browser situation is a fiasco of mammoth proprotions costing companies billions of dollars a year wasting time with supporting all the different standards, and 2) it's impossible to be really good at everything so you may have a framework that's good at most things and could work for 90% of all web apps but invariably there will be some apps it's just not well suited to (at least not without a good deal of customization). However, JSF is incredibly far from perfect. Perfect isn't even on the radar with that framework. There are far better choices and I strongly recommend you look at them.

Mario León replied on Wed, 2008/09/24 - 12:48pm in response to: Marc Stock

Totally agree with you in this.


it's impossible to be really good at everything so you may have a framework that's good at most things and could work for 90% of all web apps but invariably there will be some apps it's just not well suited to (at least not without a good deal of customization).


For the projects I had use JSF, it resolves our problems, and gave us power enough to fulfill our necessities.

Currently working with struts2, and it's doing a pretty good job

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.