An Interview with Stephane Bastian and Jonathan Cohen from JavaOne 2007

---

Speaking with Artima a few years ago, Sun Studio Creator lead architect Joe Nuxoll highlighted a key difference between the working styles of Visual Basic and Java developers. According to Nuxoll, who now works at Apple and is a member of the Java Posse, when faced with a problem, Visual Basic developers look to a component for the solution, whereas Java developers tend to look for an API to solve their needs. While each working style has its place, Nuxoll believed that component-centric solutions tended to increase developer productivity: Components can be configured by setting component properties, and often without requiring code.

In the two years since our interview with Nuxoll, Java Server Faces has emerged as the standard Java user interface component framework for Web applications. One of JSF's initial attractions is just what Nuxoll described: Working with JSF means placing a component in a page, often via a visual designer, and then customizing the component by setting component properties. Seldom does a developer have to write code to configure a JSF component.

Since JSF components encapsulate their behavior, component vendors are free to provide highly interactive components, often with very complex internal implementation. Component interactivity is frequently achieved by vendors relying on sophisticated Ajax interaction when communicating between a component's rendered state in the browser and the component's server-side representation. The result is that JSF has become a vehicle for providing interactive Ajax user interfaces, without developers having to know much Ajax at all.

But to what extent does JSF really hide Ajax complexity from developers? We asked that question from Stephane Bastian, chief Java architect at JSF component vendor Infragistics, and Jonathan Cohen, Infragistics' vice president of marketing:

If you look at our grid component [for instance], you would hook it up to a data source, and then you could tell the grid that you only wanted to display, [say], ten records at a time, and that's pretty much it. The component is going to do what is [needed] to take care of paging... The component will send an Ajax request, we do all the processing on the server-side, we do all the plumbing, we send the response back to the client, and we'll do the unmarshalling of the data, we update the DOM on the client side—all of that is taken care of by the component running both on the server-side and on the client... So far none of our users have requested any access to Ajax functionality...

Staphane Bastian, chief Java architect, and Jonathan Cohen, vice president of marketing, both with Infragistics, talk about the extent JSF hides the complexity of Ajax from developers.

What is your experience working with Ajax-enabled JSF components?

Post your opinion in the discussion forum.

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the authors

Bill Venners is president of Artima, Inc. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.