I wanted to follow up all the great content from Dan Allen on JSFSummit with some of my own, but from a component libraries point of view. One of the really nice things about speaking at a conference like JSFSummit is that you know the attendees are going to be knowledgeable and are likely already using JSF. This meant that speakers could really talk about the details of their topics. For example my talk on RichFace Component Toolbox was able to show users some of the advanced components and features of RichFaces including code examples and a demo (cruel demo gods aside). Something else that JSFSummit and NFJS get right is the length of the sessions, with 90 minutes we could really cover a lot.
Component Libraries Working For You
There was a very strong showing at JSFSummit, and this included the leads from several of the top JSF component libraries. There was Andy Schwartz from ADF Faces, Ted Goddard from ICEFaces, Cagatay Civici from PrimeFaces, and Me representing RichFaces All represented in this rare picture!. You might think that because technically we all have competing projects that this could be testy. I'm very happy to say that is not the case.
All of us, and the rest of the JSR-314 (JSF 2.0 ) expert group had many productive and enlightening discussions. Some of these were late night at the previously mentioned Thirsty Fish at the conference hotel, other were at lunch, in meeting rooms, or even during some of the talks. As Dan said there was no barrier between speakers and attendees and many times we would attend each others talks. This would sometimes spark conversations that started to sound more like a expert group meeting than a presentation. This would usually involve how to work XYZ feature or behavior into the next version of the spec. The great thing about this was that everyone participated, and voiced their opinions.
One of the large discussions involving the various component libraries involved proving one of the tenants and goals of JSF 2.0. That was interoperability, between component libraries so that developers could combine component libraries when ever needed. I am very keen on this topic, and pushed for the different libraries to collaborate on a combined example application. Perhaps we pull a data table from RichFaces, a tree from IceFaces, a menu from ADF, and a collapsing panel from PrimeFaces. This type of application would really do several things. For one it would provide proof and an example to developers that JSF 2.0 component libraries really can work together. For another it will help us all to shake out the lumps and issues developers will run into with the specification.
This second point should not be underestimated. RichFaces in its development of 4.0 has already found some items that need to be worked out
. These items represent areas of implementation that could cause component libraries to not function together, or could also point out areas in the spec that need more definition. To see a listing of some of these items check out our wiki page. I'll give you an example of one of these issues just so you can get a taste:
JSF 2.0 now has build in Ajax support that is supposed to act as a core Ajax bridge that component libraries are supposed to use. This implementation has a very simple queue associated with it. RichFaces has its own advanced queue functionality from 3.3.X that we want to bring forward to RichFaces 4.0. How do we do this without overwriting the core queue, and stepping on other component libraries toes? A few options have been discussed such as allowing developers to choose a single queue implementation that follows a defined contract so that users can switch implementations as they wish. This would be similar to JSF 1.2 where you could plug in your own view handler, a.k.a. Facelets. Another option that was discussed was to have one core implementation, but when it was a requests turn in the queue it would have full control of its behavior.
Needless to say this was not completely resolved, but gives you a taste of the efforts that will be required to make this all meld. As I said above though, what struck me was the willingness of everyone from component libraries leads, EG members, and Jim Driscoll from the RI team to work together on a solution. In the end this is going to result in a better JSF, and component libraries to go with it
Migration Strategies Were Key
Obviously one of the hot topics was JSF 2.0 support, and more specifically how users can migrate from earlier versions to new versions. This came up at literally every talk that I either gave or went to that discussed JSF 2. Users need a solid path for migration in order to leverage their efforts from the past, while moving forward with the technology. There was even a talk dedicated to migration that Kito Mann gave called Upgrading to JSF 2.
Something that surprised some developers was that although JSF 2.0 is backwards compatible, most of the component libraries could not support JSF 2.0 without some modifications. For RichFaces this is because in order to accomplish some of advanced features with JSF 1.2 we needed to interact with some of the core APIs and internals of JSF. This meant that when JSF 2.0 came along and some of those APIs changed it caused problems. The RichFaces team has been working on a solution to this, and migration strategy for our users.
We are current developing the RichFaces 3.3.3 release which will bring JSF 2.0 compatibly to the 3.3.X release branch. We should be releasing a BETA of this release very soon, and hope to have a final release of this by early next year. With this release users can begin to migrate their applications to JSF 2.0 containers, and environments. Update their own code and begin playing with JSF 2.0. It is important to note that this release is more about compatibility. You'll be able to run your existing applications with JSF 2.0, but the release will not take advantage of JSF 2.0 new features and abilities. This will need to wait for RichFaces 4.0.
RichFaces 4.0 is in parallel development, and we have already had a 4.0.0.ALPHA1 Release. This is the release that will really leverage and push the functionality of JSF 2.0. This will include new behaviors, events, and components, as well as an easy to use Component Development Kit. We hope to continue to push the bounds of the standard and begin prototyping the features that someday will be standardized in another version of JSF. We are currently planning to release 4.0.0 in early summer, but will have lots of interim releases between now and then.
So you might be asking yourself, how do I upgrade from RichFaces 3.3.3 to 4.0.0? We are working on the details of that, but rest assured we'll make it as easy as possible. This will certainly include a migration guide with step by step instructions. We'll likely also have a compatibility bridge of some type that will make migration even easier.
Feeling Good
I left JSFSummit feeling very good about a great many things. For one thing Orlando is a nice place to visit in December when you live in New York. More importantly I left feeling very positive about the JSF technology and community. I think JSF 2.0 is a great release that combined with component libraries like RichFaces, and other features in EE6 like CDI and Bean Validation really make an application stack that is hard to compete with. I'm also very excited about RichFaces future, and the great community and developers that we have.
Thanks to everyone that attended, and all the speakers and expert group members that were there!!
[javaserverfaces.org [RichFaces Project Site] [Downloads] [RichFaces Twitter]
