Adam Winer is the Oracle representative on the JSF Expert Group responsible for JSR-127. We sat down with Adam for an interview about JSF, its past, present, and future.

Tell us a little about your work at Oracle?

I've been working for Oracle for the past 10 years focusing on user interface frameworks development for about 8 of those years. I've worked on the MacOS version of a client-server UI framework, then was part of the team that developed the EWT set of Java components, which extended the standard AWT set before Swing came along. In the last 5 years I've been working in the UIX and Faces group. Today I'm the architect and project lead for the Oracle ADF Faces Components.

When did you join the JavaServer Faces experts group( JSF EG)?

I joined the JSF EG when it was first created back in May 2001, I've been one of the most active members of the EG from its inception. Oracle saw the value of a framework for easier Web interface development, and we knew we had a lot to contribute to that effort based on our experience. So we were quick to jump on the opportunity to influence the creation of this standard.

Has the UIX experience contributed to the development of JSF?

Yes it did quite a bit. You need to remember that we have many users of UIX both outside as well as inside Oracle - products like Oracle Enterprise Manager, Oracle Discoverer, and Oracle E-Business Suite all use UIX extensively - so we knew quite a bit about what we need from a Web interface development framework.

While creating JSF we actually used many of the things that we came up with for UIX. Things like the component-renderer separation - which separates the component appearance from the component functionality - is something we had in UIX for a while now. This architecture frees the developer from worrying about the actual interface, and let him focus on the functionality. The renderer can then be done in different ways for different agents.
Also, the basic existence of a tree-of-components model was something we found invaluable in UIX, and pushed for in JSF.

We also felt the absence of some much-needed features in UIX, like a component-level events and better request processing, and could contribute that experience back to JSF.

What is the current status of JSF?

We've seen a very good adoption rate for JSF both by developers as well as companies that develop tools and components for JSF. For a young standard this really makes us happy, it shows that we are addressing an actual need and developers see the value in a solution like JSF. On the other hand, like any technology that is just starting out, there are still some issues that need to be ironed out to make the JSF experience even smoother.

What is your take on the JSF vs. Struts debate?

Well Struts has been around longer than JSF and it really has a big following out there. I think it does the Controller part of the MVC architecture very well, but I also think that JSF is superior in its implementation of the View part. So, I think we might be seeing some people using a combination of the two in the near future, especially if they already have Struts knowledge. It really depends on your background, if you didn't use Struts before, JSF gives you everything you need both in the View and Controller layers - and you can follow a JSF route from start to end.

Where do you see JSF going next?

Well our next release will be 1.2 and it will come out with J2EE 5.0. One of the things that we are trying to work on now is better alignment between the different Web tier technologies in J2EE. We have a common interest group that has people from the JSF, JSP, JSTL, and Servlets expert groups and we all work together to make the overall experience for Web development better. Things that we are discussing will influence the JSRs that each one of the components has, and will make it easier to integrate the technologies.

For example an issue that we currently have is that we are not very happy about the way that JSF work inside JSP. A better integration would allow us to take care of things like better content interweaving, firing events before a page renders, and other page life-cycle issues. The work that we do in this group will have an impact on both the JSF and JSP specification to create a better overall development experience.

One thing that people need to remember is that JSF is only a specification, not an implementation. The benefit of JSF is that now components from one vendor or developer can work with components that others have developed - and you can combine all of them into a single application. I think a lot of the success of JSF in the future relies on good implementations. Implementations can contribute back to the specification - and the JSF community then benefits from that as well.

So how does ADF Faces contribute to the JSF ecosystem?

We contribute in two main ways. First, we can tackle some of the bigger gaps and holes in the JSF specification. We can implement solutions for these in our library on top of the specification, then bring solutions back to the EG and use our work as the base for a solution in the official specification. I should note that we make sure to build our preliminary implementations portably so they'll run on any compliant version of JSF.

An example of a problem we solved in ADF Faces is the mismatch between the JSTL foreach tag and JSF. We are now taking this solution and bringing it back as a possible solution to the expert groups. Other examples include mechanisms for passing values between two JSF pages, something that a lot of JSF developers have problems with, and client-side validation, something that many JSF developers have been asking for.

The second way we contribute to the JSF community is by offering JSF developers some unique features that will make their JSF user interface better and their development easier. For example JSF comes with only a limited number of components, ADF Faces adds to this a very rich set of components, giving developers a more complete set of components for their application, and saving them the need to develop these from scratch. We also implement our components in such a way that they work on other devices, so for example you can run your application, unchanged on PDAs using ADF Faces.

Another very cool feature that we offer is the ability to customize your look and feel. Although it is still not exposed in the current early releases of ADF Faces it is something that is coming soon. You can see how it works by looking at UIX based sites like blogs.oracle.com that let you change the look and feel on the fly.

One more thing that came out from our experience while developing and testing ADF Faces is a need for a specification that will detail how to integrate JSF components into development tools. We are now leading an effort to create a design-time metadata for JSF components and we have an initial suggestion for it.
Once this is in place, you'll be able to seamlessly pick up any JSF components and use it in any JSF supporting IDE.

Any last words before we say goodbye?

I would like to encourage people to download ADF Faces now and give us their feedback on what they like and what they don't like. Their input at this stage is really critical to what they'll get out of JSF not only from the Oracle side, but from the JSF community as a whole.