When Oracle Corp. bought Sun Microsystems Inc. and took Java under its wing, some thought that JavaServer Faces (JSF) would go the way of Latin and Sanskrit. Contrary to those predictions,
“In April 2011, we started work on the next major revision of the JSF specification, version 2.2,” says Ed Burns, consulting member of the Technical Staff at Oracle and the specification lead for JSF. Just last week, he said, Oracle "released a milestone 1 snapshot implementation of that specification, which is still very much in active development.”
“It's in a healthy state,” says Ray Ploski, director of Developer Programs and Strategy at Red Hat. Two implementations of JSF exist, Mojarra and MyFaces, and there is “a very competitive and rapidly moving component ecosystem surrounding it. The spec is under active development, bringing in the changes recommended by this large ecosystem it supports,” Ploski said.
Companies that are using Java Enterprise Edition often adopt JSF, says Kito Mann, principal consultant at Virtua, Inc. “It’s more popular for applications that have complex user interfaces,” he says, noting that JSF increasingly is used in insurance, government and financial applications.
“A lot of large corporations and government organizations are adopting JSF as a standard throughout the organization,” said Ted Goddard, chief software architect at ICEsoft Technologies, Inc. “That fits in with the sweet spot of what JSF is intended for – highly interactive enterprise applications,” he added.
Meanwhile, Goddard advises choosing a component library and using it throughout the application being developed. “Avoid the use of component bindings in [JSF], because that drags the model into the view and makes it more difficult to maintain the code. [Developers] need a more declarative approach when building [JSF] pages,” he says.
Another useful best practice, according to Burns, is to not “blindly buy into the hype that Data Transfer Objects (DTOs) are an anti-pattern. When used correctly, and especially with JSF, DTOs can provide just the right abstraction that enables loose coupling and minimizes application maintenance headaches,” he says.
Developers also need to work with the framework instead of against it, says Mann. “Sometimes people add functionality and features to their application and build a framework on [JSF] without understanding the way that it works,” he says.
A pet peeve of Mann’s is letting exceptions “bubble up” to the JSF exception handle. “Don’t eat exceptions,” he cautions. “It screws up the user experience because something is out of sync in the application.”
If developers follow best practices, JSF is an excellent complement to HTML5 for building front-end applications, particularly as mobile browsers continue to gain steam. All mobile browsers are HTML5 browsers, according to Goddard.
“HTML5 lets you put most of the UI processing on the client, but you must very carefully consider the consequences of that choice in terms of security, and cross-browser portability,” Burns says.
JSF can target different markup types, says Mann. “You could have different pages for HTML5 and an older version of HTML,” he says. “You could have different pages for mobile devices, and they could all use the same back-end code.”
Expect more opportunities for HTML5 with JSF 2.2, Mann says. Better portlet integration and flow management are expected in 2.2. “One of the things we're looking at is … reducing the server side footprint,” he says. Cloud support is coming as part of Java Enterprise Edition 7, and JSF will work well with that, since it already runs in the cloud.
“Because of the way [the] technology is defined, it’s good at adapting to other display models,” Mann says. “The same application can be updated to work with a smartphone or HTML,” and that’s one of the biggest benefits, that JSF can keep supporting new technology as it becomes available.
Christine Parizo is a freelance writer specializing in business and technology. She's based in West Springfield, MA. Contact her at firstname.lastname@example.org.