JSF Central - Interview with Craig McClanahan
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
Community Chat
 
Interview with Craig McClanahan
(continued)
by Kito D. Mann
06 May 2007 01:30 EDT

Craig McClanahan, Sun's Web 2.0 Architect for its Java Tools division and lead for Apache's Shale project, talks about JSF, Shale, development tools, and dynamic languages.


KM: There's this new project on java.net called Woodstock, which is a set of AJAX-enabled JSF components. What can you tell us about it?

CM: Woodstock is the latest installment in the trend towards open sourcing Sun software technologies. It is comprised of the JSF component library that we have been shipping (previously closed source but freely redistributable) with Java Studio Creator and Visual Web Pack. Now, developers will have available another comprehensive set of commercial quality visual components.

In addition, we open sourced some tooling we used internally to do some of the most boring parts of JSF component development (like creating the tag classes and the TLD). We used the annotation processor capabilities that came along with Java SE 5 to write a generator that extracts the information it needs for these purposes, plus what is required to create design time behavior for JSF components inside Visual Web Pack, as part of your build process. This processor is not at all specific to the Woodstock components—it could be used by anyone building a component library—so it's likely that this will be a separately released artifact of the Woodstock project.

As background, these components are the latest evolution of the output of a group of developers who have long been chartered to build UI functionality for all of Sun's administrative applications (such as the console for the App Server or Portal Server). When the Creator team identified a need for a component library beyond just the JSF components defined in the spec, we initially considered building our own. But it seemed like a much better idea to join forces and collaborate, so that's what we did.

Over time, we have in mind an evolution in the architecture of these components to support emerging trends like Ajax and rich Internet apps. They will continue to form the UI basis for web applications that Sun builds into our own products, but they are also available under an open source license for everyone else to use (and contribute to) also.

KM: When do you think the first official GA release will appear?

CM:
The Woodstock components are available today as a GA release (version 4.0.1 can be downloaded from https://woodstock.dev.java.net). This is a repackaging of the internal to Sun version 4.0 release of these components that was (among other things) included with Visual Web Pack).

We are targeting a 4.1 release during the third quarter of 2007, which will include several new components, plus more Ajax support on existing components. Further planning will be documented on the roadmap page at the project web site: https://woodstock.dev.java.net/ProjectRoadmap.htm.

KM: Excellent. When is the next release of Java Studio Creator due?

CM:
At the moment, we're focused on porting the features from Creator 2 that didn't make in into the VWP codebase so that it can all be included in NetBeans 6 later this year. One of the interesting questions, though, is whether people also still want a tool focused solely on visual web development (which we can create by subsetting NetBeans 6 functionality), or whether it is fine just to have an all-in-one tool that the user can customize to focus on what they want to work on. I'd definitely be interested in feedback on this point.

KM: I always felt that the simplicity of Creator was a big strength for it. For example, instead of letting you choose from 50 different types of projects, there are only one or two choices. However, I imagine there's a way you package the Visual Web Pack as a specialized Creator-like product without too many other features exposed.

CM:
We're definitely looking at packaging, and ways we can make the right amount of functionality available at a particular time, without either overwhelming the user, or letting him or her mistakenly think that a particular area of functionality is not supported.

KM: Many people think the set of components that are defined by the JSF spec aren't adequate for building full-fledged applications. Do you think any of the Woodstock components might make their way into the spec?

CM:
There is an interesting decision here for the next rounds of JSF development. Should the spec focus solely on the fundamental APIs, or should it also focus on increasing the set of components that are part of the standard? In some ideal sense, I wish that we had been able to just do the APIs in JSF 1.0, and not had to get distracted fleshing out the basic HTML renderkit as well. But had we done that, it would have been impossible for someone to take that initial release and actually use it to build apps with—it would have been a chicken and egg situation where app developers waited for components to become available, and component developers waited for there to be a market for components that conformed to the standard to emerge.

Instead, the fact that we standardized a basic set of components meant that JSF was at least minimally useful out of the box, and kick started one of the key goals of the whole JSF effort: creating a marketplace for multiple libraries of high quality components that could interoperate because they were based on the same API standard. In today's market, this reduces (in my mind) the need to focus primarily on adding standard components.

That being said, the value of having a richer set of standard components is that developers can always expect them to be available. If there is market demand driving this, there are lots of clever ideas in the Woodstock components that can serve as input to that ... but you can make the same statement about many of the other libraries out there as well. The interesting balancing point is defining standard components that have sufficient functionality for basic requirements, but that do not stifle innovation and competition in the third party component library marketplace.

KM: It's definitely a tough issue. I'll be posting a couple of JSF 2.0 editorials here on JSFCentral in the future.

CM:
Yes, it is. My guess is that there will indeed be some additional standardization in this area, but that will ultimately be up to the expert group to decide.

KM: Thanks for your time, Craig. It was a pleasure talking to you.

CM: Thanks to you as well—it's been enjoyable.



RSS feed(all feeds)

The Editor's Desk
Podcasts
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.