Matt Raible has been building web applications for most of his adult life. He started tinkering with the web before Netscape 1.0 was even released. For the last 16 years, Matt has helped companies adopt open source technologies (Spring, Hibernate, Apache, Struts, Tapestry, Grails) and use them effectively. Matt has been a speaker at many conferences worldwide, including Devoxx, Jfokus, ÜberConf, No Fluff Just Stuff, and a host of others. Matt is a DZone MVB and is not an employee of DZone and has posted 149 posts at DZone. You can read more from them at their website. View Full User Profile

Hyperproductive JSF 2.0 with Ed Burns at Jazoon

  • submit to reddit

This morning, I attended Ed Burn's Talk on Hyperproductive JSF 2.0 at Jazoon. As you might know, I've been a critic of JSF for many years. However, it is one of the most used Java web frameworks, so I was hoping to learn how it's improved in the latest version. Below are my notes from Ed's presentation.


Ed's Plan for our Time Investment:

  1. Define a productive development environment
  2. JSF for greenfield and brownfield projects
  3. List the top 9 productivity killers with JSF projects and solutions

"I am always doing that which I cannot do, in order that I may learn how to do it." -- Pablo Picasso

Software is an executable representation of knowledge, a byproduct of learning how to solve a problem. Knowledge is something that changes as more information comes in. A productive environment makes it as easy as possible to learn how to solve a problem. Learning is an iterative process. Early iterations don't need to be optimal. Later iterations do ... and they need to be maintainable. First is the hardest. Fast iterations are they key. Spring Roo and Play are examples of frameworks that make the first iteration very fast.

You should use a tool to jumpstart JSF development: copy from an old project, use a Maven archetype or use your IDE. With greenfield development, you don't have to bother learning the byproduct of other people's learning. It's a great opportunity to pad your resume with the latest hot technologies. With brownfield development, it's vitally important to understand the existing solution and hidden assumptions. You're also much more constrained in your technology choices. If you want to change, you'll need to come up with a migration strategy, which can be difficult. JSF works well for both because it's not just a runtime framework, it's also a conceptual framework. You need to understand how your framework handles data conversion, validation, page flow, persistence integration, I18N, L10N, A11Y, Web standards and user friendliness.

Top 9 JSF Productivity Killers:

  1. Time wasting deployment step
  2. The perils of "there's more than one way to do it"
  3. Lengthy and painful developer on-boarding process
  4. Misused logging and misunderstood error messages
  5. Phantoms
  6. Under-utilized developer tools
  7. Premature optimization
  8. Difficulty in doing TDD
  9. Lack of an app framework

Time wasting deployment step
ZeroTurnaround solves this problem with JRebel, but there's other ways to do it. Some of the killers of flow state: 1) one large war file, 2) underutilizing dynamic language features, 3) complex server environment and 4) build process is redoing work unnecessarily. To stop the time wasting deployment step, the most important things you can do are as follows:

  • Configure your IDE correctly. In Eclipse, compile directly into WEB-INF/classes and use continuous compilation. With NetBeans, use GlassFish.
  • Don't do control-flow programming in XML.

Ed then showed a simple demo that showed how you can use Groovy to create a JSF UI Component. He also mentioned that Groovy can be used to author any JSF artifact. The benefit of this is you can simply edit and save a .groovy file without having to recompile or redeploy. Unfortunately, using Groovy didn't eliminate the XML syntax for pages or the XML for defining UI components.

The perils of "there's more than one way to do it"
JSF is very flexible, but flexibility is, more often than not, abused. There's a lack of convention for common things (e.g. master-detail, JSF concepts like converter, validator, etc.). The best way to fix this is to establish the norms for a project and stick with them. For example, Neil Griffin has a good blog entry for the different kind of managed beans you can create. Develop recommendations like Neil's and use them on all your projects.

Lengthy developer on-boarding process
Stick with standards when possible (at least have a common project description and build system across projects). Be committed to periodic cleanup cycles, including documenting for re-use. Pick one JSF component library and stick with it. Support for mixing and switching component libraries has improved with JSF 2, but it's still recommended you use only one.

Misused logging and misunderstood error messages
JSF is notorious for cryptic error messages and very long stack traces. It's still a problem, but the JSF Team is still working on improving them. Good tip: use the <ui:debug> tag. Its recordStateSize="true" attribute can be especially useful. If you're using PrimeFaces, add trace=true to request URLs.

Phantoms is when running code is not the same as the code you are modifying or wrong version of library gets picked up. You should have the capability to hit breakpoints anywhere in your entire software stack, including core Java sources. This is one of the most useful things about open source software. Solutions to phantoms: 1) put a timestamp on every redeploy and have the timestamp appear in the system log 2) write the running library stack to the system log (each library and version being used) and make it easy to compare one developer's runtime stack with another's 3) consider doing all work in tightly controlled VMs (checkout the VM at the beginning of the day, do your work, commit your changes and throw your VM away at the end of the day).

Under-utilizing developer tools
Make sure everyone has the fastest machines available and as much screen real estate as desired. Hardware is much cheaper than developer time. Another tip is to use Hudson as your butler. It's not just the team CI server. In other words, take advantage of automation wherever you can.

Premature Optimization
Keep in mind the trade-offs between readability and performance. When using frameworks such as JSF, don't try to outsmart the implementation. Rather, use the framework as intended and use open-source contributions to treat performance problems. Example, EL expressions got a lot faster between EE5 and EE6. If you spent time trying to optimize EL expressions, you might've been wasting your time.

Difficulty in doing TDD
Try to figure out why TDD is difficult in your company. For JSF, strongly consider JBoss's JSFUnit. Write your testcases to extend from Cactus ServletTestCase and leverage HtmlUnit (JSFUnit does this for you).

Lack of an app framework
Create common components: login panel, CRUD components, etc. If you don't have an app framework, build one over time.

This was an interesting talk by Ed. The dynamics of the room where a bit interesting. Jazoon is held in a movie theater, much like Devoxx. However, it appears there's a spotlight on the speaker that makes it very difficult to see the audience. I don't remember having this problem at Devoxx. Ed asked the audience quite a few questions, but it seemed he had a lot of difficulty in seeing if folks raised their hands. This made for some periods of awkward silence.

Personally, I was hoping to learn some new whizbang tips about JSF that I was not aware of. Unfortunately, I didn't learn anything new and wasn't that impressed with the Groovy demo.

I think Ed's tips about things outside of JSF were good, especially buying developers good hardware. I've seen many companies, including my current client, skimp on developer hardware and cause developer frustration because of it. I think it's great when companies provide developers top-of-the-line hardware and eliminate frustration over CPU and memory resources. LinkedIn and Time Warner Cable both provide their developers with Mac Pros and MacBook Pros as well as huge monitors. IMO, this is one of the best benefits you can provide your engineers.



Published at DZone with permission of Matt Raible, 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.)


Kai Wähner replied on Fri, 2011/06/24 - 2:14am

Hey Matt,

I really like JSF 2.0, it is much more productive than older versions. I think many (other) people still use their old knowlegde of JSF 1.x and do comparisons as they do with EJBs. Of course, JSF is not as productive as Spring Roo, Play or Grails.

Nevertheless, I think it is the best choice for a server-side web framework if you have to realize a really huge web application with many developers (besides CRUD). The productivity of Spring Roo is awesome - but only for the initial startup of a web application (see my blog "When to use Spring Roo and when NOT to use it":

I listened to your web framework comparison at Java Symposium 2011 in Las Vegas some months ago (I especially liked your presentation style) and in my opinion JSF is not as bad as you make it :-) Nevertheless, I want to mention that things like TDD with JSFUnit is everything else, but NOT productive! It is a lot of effort...


Best regards,

Kai Wähner (Twitter: @KaiWaehner)

BTW: I also had problems with the lights in my Jazoon talk on Tuesday about Apache Camel. Besides, the cinema environment is awesome for such a conference!

Jacek Furmankiewicz replied on Fri, 2011/06/24 - 8:18am

For CRUD applications, none of these can hold a candle to Django and its admin interface. We're doing all of our server-side programming in Java/Spring and all of our web portals in Django.

It's time Java developers got off the "Java is the best solution to everything" bandwagon and expanded their knowledge.

P.S. BTW. we got off JUnit as well and are doing all of our integration testing using Python-based BDD tools, including testing of web UIs via Selenium...all integrated into our regular Maven builds.

Java is a horrible language for writing unit tests in...the verbosity really gets you. We've created 140+ Junit integration tests in a year...and 800 BDD integration tests (via the Python Freshen library) in 3 months! Now that's productivity.

Jonathan Fisher replied on Fri, 2011/06/24 - 11:49am

>>It's time Java developers got off the "Java is the best solution to everything" bandwagon
>> and expanded their knowledge.

I think it's time for the dynamic language crowd to take a less condescending and provocative approach of evangelizing their pet language.

Otengi Miloskov replied on Fri, 2011/06/24 - 12:55pm in response to: Jonathan Fisher

Actually Jacek is a Java developer but he realized that Dynamic languages are good in some solutions or problems to resolve and not as a some religion zealot's that using just 1 language for everything.

Jonathan Fisher replied on Fri, 2011/06/24 - 1:11pm

>>some religion zealot's that using just 1 language for everything.

I'm not opposed to other languages and I get to use a wide variety of them in my daily job.

I'm opposed to the implication that using Java makes me a zealot. The only zealotry that appears to be happening is from the dynamic language crowd.

Jacek Furmankiewicz replied on Fri, 2011/06/24 - 4:41pm in response to: Jonathan Fisher

To clarify: we are a Java shop. All of our stuff is Maven / Spring / Jetty / Hibernate / CXF on CentOS. Hardcore Java stack and it serves us great.

But for web CRUD apps, having to code forms/tables by hand is really a slow dev process. I developed a reasonably production ready Django admin app with about 25+ CRUD screens in 1 week! And that's with zero prior Python/Django knowledge.

It's an eye opening experience.

Jonathan Fisher replied on Sat, 2011/06/25 - 12:02pm in response to: Jacek Furmankiewicz

Much better :)

Henk De Boer replied on Sat, 2011/06/25 - 12:05pm in response to: Jacek Furmankiewicz

It's time Java developers got off the "Java is the best solution to everything" bandwagon and expanded their knowledge.

But doesn't the same thing hold for Python zealots? It seems that pretty much the only reason why they badmouth Java so much is because they have a stake in people adopting Python

But for web CRUD apps, having to code forms/tables by hand is really a slow dev process. I developed a reasonably production ready Django admin app with about 25+ CRUD screens in 1 week! And that's with zero prior Python/Django knowledge.

Well, I got the ultimately CRUD application in no time at all by installing PGAdmin :P

Seriously, as you mention, it might indeed work for an admin app, but most apps are actually for non-admin users. With JSF 2.0/Java EE we recently build an (admittedly simple) web application from scratch with some 7 CRUD-ish screens in 2 days. First day we set up the JPA entities and their associations, added bean validations constraints and set up a simple DAO structure for each of the main ones. Second day we started with the JSF master template, and two sub-templates for resp. master and detail pages. We then created a few composite components to easy building forms (e.g. a simple aggregation of a label and an input field), and created the 7 mentioned screens during the rest of the day.

Now, we do have a lot of experience with JSF and Java EE in general, so this was a relatively easy task for us, but it does show off what's possible I think. We also had a lot of experience with JSP, Servlets and JDBC at one time. I know these technologies are at the other hand of the scale, but I vividly remember I took us -way- longer to pull of something like this. Things like validations via bean validation, view parameters, the view scope, declarative transactions, the easy with which you pull an object out of the DB etc all make for a very productive environment.

Edvin Syse replied on Mon, 2011/06/27 - 2:39am in response to: Jacek Furmankiewicz

Jacek, if you for some crazy reason code your forms/tables by hand, it is not a matter of wrong language you're dealing with, just the wrong approach to the problem. If your framework doesn't provide abstractions for this stuff, you create the abstractions _once_. I create HTML forms in my controller like this (Groovy, but that's really besides the point):

Form.create {
    fieldset("Please log in")
    text("Username", "username").required()
    password("Password", "password").required()
    submit("Log in", "login")
    onSubmit {
        if (loginok)


In my view (Freemarker) I do:


Same kind of abstraction for HTML tables.I guess for plain Java I would have used the builder pattern to make the code look almost the same.

Sirikant Noori replied on Sun, 2012/01/15 - 12:33pm

I really like JSF 2.0, it is much more productive than older versions. I think many (other) people still use their old knowlegde of JSF 1.x and do comparisons as they do with EJBs. Of course, JSF is not as productive as Spring Roo, Play or Grails.

Comment viewing options

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