This week we released our JSF 2.0 Refcard. I had the chance to ask the author, Cay Horstmann, some questions about JSF 2.0 from what it's all about, to discussing the future for the framework.
Click here to download your free JSF 2.0 Refcard now!
James Sugrue: Could you please introduce yourself?
Cay Horstmann: I am author of Core Java (Sun Microsystems Press, 8 editions since 1996) as well as numerous college books, and co-author of Core JSF (with David Geary, Sun Microsystems Press). I am a professor of computer science at San Jose State University. For four years, I was VP and CTO of an Internet startup that went from 3 people in a tiny office to a public company.
Sugrue: What exactly is JSF? What problems does it solve?
Horstmann: JSF is the "official" web framework of the Java EE stack. It is a *component* framework: developers assemble web applications from prebuilt components, roughly analogous to Swing. The components are connected with plain old Java beans for the application logic. JSF achieves a clean separation between the view and model layers: The visual layout is not polluted with application code, and you need not write code to produce HTML tags.
Sugrue: What is so different in version 2.0?
Horstmann: JSF 1.x didn't really live up to the promise of easy development--there was a fair amount of XML boilerplate, it was too hard to write your own components, there was no way of factoring out common parts of a page (such as headers or menus), and error handling was abysmal. JSF 2.0 solved these problems by incorporating and improving the "facelets" library, and by adopting annotations, just like the other Java EE 5/6 technologies. Now the XML boilerplate is (almost) gone, components can be composed declaratively, there is a templating system, and, most importantly, the Stack Trace from Hell, is replaced by programmer-friendly messages pointing to the file and line that caused the problem.
Sugrue: What makes it better than other technologies like Struts?
Horstmann: Struts does not focus on reusable components. For example, in JSF, there is a table component that you hook up to a provider of tabular data. In Struts, you would manually render the rows. The advantage of a component model is that there are smart people who write components. For example, consider rendering a long table--you'd want a "pager" for viewing a batch of rows at a time. With JSF, you can get such a component and just drop it in.
With the advent of Ajax, this has become even more important. Some people enjoy hand-crafting Ajax traffic. I am not one of them. I prefer to spend my time on programming application logic. With JSF, I can leverage the fact that someone else has implemented the Ajax goodness in their component. Ajax is another important reason for moving to JSF 2. In JSF 1, every component library used their own Ajax implementation. This has now been standardized, which should lead to better interoperability between component libraries.
Sugrue: What is your number one tip for people who want to get started with JSF?
Horstmann: To start with JSF 2, or if you cannot, to use facelets. And if you can, use a real application server such as Glassfish, not Tomcat.
Sugrue: What is coming up in the future for JSF?
Horstmann: I think the most important next steps will be JSF 2.0 component libraries and IDE tooling for JSF 2.0.
The other exciting technology to watch is JSR 299, formerly known as WebBeans. It provides "conversational scope", which enables you to manage the scope of objects over multiple pages in different browser tabs, and integration with stateful session beans, which makes it very easy to scale your app.
Beyond that, I look forward to more ease-of-development improvements and some cruft removal.
Sugrue: Would you recommend any tools or IDEs for JSF developers?
Horstmann: Sure--you can use Eclipse or Netbeans today. They do a good job with basic page authoring and, of course, a great job with the Java part. They both have great debuggers and provide hot deployment to your app server. It would be nice if they had better visual page designers and better autocompletion for the expression language that you use to hook the Java code to your JSF pages, but that will surely get better.