Don't expect any earth shattering changes in JavaServer Faces (JSF) 2.2

Unlike the full increment 2.0 release, the latest edition of JSF is more evolutionary than it is revolutionary. "JSF 2.2 is smaller in size and ambition than 2.0; 2.0 was a giant release, but 2.2 adds a smaller feature set" says Ed Burns, the JSF spec lead and a senior Java engineer at Oracle. "Not every release can be a blockbuster release."

But that doesn't mean JSF 2.2 doesn't include a few new blockbuster features. You may have heard of ADF task flows or Spring Web Flow, both of which are designed to work as control structures for Web sites with complex navigation graphs. The new blockbuster feature in JSF 2.2 is FacesFlows, which takes the best parts of other flow-based technologies and standardizes them. With FacesFlows, JSF has worked to take advantage of a variety of new features that have been added to JSF since the last full increment release and subsequently standardize the manner in which Web flows are programmatically managed in Java-based Web applications.

"Standards are for standardizing, not innovating," says Ed Burns. Hopefully this implies that that if you've got some experience managing Web flows with either MyFaces CODI or Spring-based implementations, you shouldn't have any difficulty picking up the model that has been standardized in JSF 2.2. Just think of FacesFlows as a conglomeration of all of the most effective features from competing technologies all rolled into one specification that moves in step with all of the latest Web-based technologies.

Sadly, many of the examples demoed in the JavaOne session used XML to manage the flows, although there still is plenty of hope for those who prefer to code as opposed to editing markup. The specification strongly supports annotations, and flows can even be written in alternative languages like Groovy if the developer is so inclined. Furthermore, the spec also supports implicit definitions that can significantly simplify flow creation and management.

The specification still hasn't been completely solidified, but you can download a working implementation from the nightly builds. The JSF spec team is still interested in input from the community before the book is closed on the first iteration of the spec.

Without a flow-like technology, a website is, as Ed Burns describes it, "just one large flow where everything is visible and there is no logical partitioning," and that just doesn't make sense for large and complicated websites. It's been a long while in the coming, but it is nice to see that JSF has finally taken the innovations seen from similar, forward thinking frameworks and finally standardized flow technology as part of the specification. 

No.

Next question.

+1

If you're not using bloated JSF to begin with, you're not even going to consider this.

 

If you're not using bloated JSF to begin with, you're not even going to consider this.

What's bloated in JSF?

Someone might think that in Java world the only usable technology is the one that's standardized. Also when there’s and there will always be only one implementation of the standard (RI) and when the implementation is just a bunch of existing classes with some packages renamed from e.g., com.ibm.something to javax.something.

Classical example is JSR-110 (Java API for WSDL) – does anyone remember it’s “standard”? Or is it just good old wsdl4:wsdl4j:1.6.2 at Maven Central? It’s an old example (2006-11). But the quest for “standardization” is on. For JavaEE 7 it’s e.g., JSON. We have good Jackson from CodeHaus, but hey – it’s not a standard – so it’s *legacy* - don’t use it!

This situation reminds me of “JavaEE advocates” motto, that “interfaces became absolutely optional” – of course there’s truth in it when there’s only one implementation. So why there are “standards” created for existing implementations when all we need is just a good, open source library with an infrastructure (JIRA, Git/SVN) where we can track what’s going on?

Back to the Web flow – do we have to standardize it just to start using it? I’d recommend just typing “java web flow” in your favorite search engine…

Regards

Grzegorz Grzybek

It's absolutely a viable idea to take the best parts of what has proven to work in practice and standardize that.

The idea of standardization is two fold: there's a clear specification of some given functionality and by implementing that different implementations can claim a given level of compatibility with each other.

E.g. before we had Hibernate and TopLink. Two competing technologies that had the same base model for their ORM, but they were not compatible with each other. With JPA as a base line for ORM technology that both Hibernate and TopLink (now EclipseLink) support, there's the possibility to move code between those two (and other implementations as well). It's not overly clear what's meant by being "Hibernate compatible", as that would mean cloning its entire code base. Every little nuance and bug would have to be duplicated. On the other hand, it's really clear what's meant with being JPA compatible. There's a clear spec and a TCK to prove it. (the TCK could be improved upon by being freely available and open source)

Secondly it means something is available in the "core" of some technology.

This is not necessarily related to standards. For example, you have PrimeFaces and you have some dude who's making PrimeFaces Extensions. If something appears to be working really well, then PrimeFaces adopts that extention into its core. We've seen that happen with many open source projects, e.g. Postgres, Firefox, and many others.

In this case, it means flows will be available in base Java EE. ADF being an extention to Java EE and JSF already can leave the base implementation of its flow feature to the core and concentrate on advanced functionality build upon it. Spring will probably not build on Faces Flows, but who knows. And over time, other frameworks may spring (no pun) up that will build upon Faces Flows and provide new exciting features that would have been too costly to implement otherwise.

It's absolutely a viable idea to take the best parts of what has proven to work in practice and standardize that.

I'm not against standards, I'm against refactoring some existing and working libraries into javax.* packages and to rt.jar - such as JaxWs. That results in problems with upgrading versions of something which should not be considered a "standard library". JaxWS is good, but why put it into rt.jar

With JPA [...] there's the possibility to move code between those two (and other implementations as well).

Great - that's JavaEE's theme. But in practise there's little chance that you'll change one implementation to other. 1 in 10 enteprise projects is new - other are just maintaining and extending existing projects. Of course specs and TCKs allows some level of "switching implementation" but in the long term switching means just using another documentation to look for extensions and quirks (in case of JAXB that's e.g., configuration of mapping simple XSD types or kinds of collections).

There's a clear spec and a TCK to prove it.

By the way - can you pass me a link to JaxWS TCK's source code? I can't find it...

In this case, it means flows will be available in base Java EE. [...] Spring will probably not build on Faces Flows.

In practice, when something is "in base Java EE" then it's a little bit harder to ship newer version of specification/implementation with your app running on older application server. Especially if this server is used to run more than one application. Believe me - there are apps still running on WebSphere 6 and WebSphere 7 is still being considered as "new" in some organizations. Try replacing JaxWS implementation in WebSphere 7 (it's Axis2 in some SNAPSHOT version - see WAS7/plugins/org.apache.axis2.jar) and try not to break existing applications...

If I'd like webflow, I'd just pick some proven library and ship it with my application. That's main problem with JavaEE/JavaSE - theirs designers think that someone might need some functionality (e.g., JaxWS) but the developers are not smart enough to find the proper Jar, so "let's make it a part of rt.jar / put it into parent class loaders of application servers". Why the heck they put: activation, jws, management, naming, transaction, or even xml subpackages of javax.* into rt.jar?! I just hope that when modularity finally arrives in JavaSE 10 the rt.jar will also be modularized and I'll be able to select which particular version of JAXB/JAXP/JAXWS I'll use...

regards

Grzegorz Grzybek