Joe Ottinger had the opportunity to talk with Amy Fowler, a senior staff engineer at Sun Microsystems and one of the founding members of the Java Swing GUI Toolkit, and discuss Swing, JSF, the JDNC, and some general trends in Java.

JDJ: Can you tell us what your role is at Sun now?
Amy Fowler: Officially, I'm the technical lead of the Java Desktop Network Component (JDNC) project, which aims to simplify Java desktop client development for Web-enabled applications. Unofficially, I'm a rich-client agitator. I've been at Sun forever and have been an engineer on the J2SE client team since the days we called it the "JDK" and there were a total of eight packages. Most of that time I've spent on the Swing team, with a year-long tour of duty in J2EE as the JSF spec lead, trying to define a component model in the otherwise amorphous Web tier. So I have history, perspective, and a genuine passion for Java and user-interface software.

JDJ: What do you see Java being like in the future?
AF: Almost nine years ago Java hit a developer productivity sweet spot by providing a language that made just the right set of trade-offs between power and complexity. As the demands on software grow (more, better, faster, prettier), Java must target that sweet spot on a grander scale by making a more-capable platform easier to use. Tools are in there somewhere. If I may dream a bit, I hope Java will take advantage of the increasingly mind-blowing GPUs to deliver us from '80s-style user interfaces.

JDJ: As a JCP member (and former spec lead), how well do you think the JCP works? Are there any improvements that could be made.
AF: From my vantage point as a Sun engineer leading a JSR, it seems the JCP is a reasonable framework for involving the Java community in the evolution of Java standards. I think the process works best when a JSR is kicked off with a concrete proposal and working implementation as a starting point. Doing design by committee is like trying to run in the shallow end of a swimming pool.

One change we might need is an expiration on stale JSRs - the ones that get filed but never kicked off. If the leading company fails to take action, it shouldn't lock out other interested potential leaders/participants.

JDJ: Where do you see JDNC falling in the implementation hierarchy? Who are the primary users and developers, and when can we expect to see it in the marketplace?
AF: JDNC fits quite nicely on top of Swing and Java 2D. We've meticulously layered the implementation of JDNC so that developers can take advantage of it at many levels. If you're a Swing developer, you can use our Swing extensions package to get features like integrated table sorting/filtering/highlighting, data streaming, data binding, etc. The higher-level JDNC components wrap Swing and our extensions to provide a simpler API for common use scenarios. This API is targeted at Java developers who aren't necessarily Swing literate. Finally, the XML Schema layers on top to provide a declarative alternative to constructing the GUI, and this can be used by markup developers who may or may not know Java.

My June '03 white paper (www.javadesktop.org/articles/JDNC) focused mostly on the XML layer, but we've spent most of this last year developing the underlying Java APIs, whose simplicity should be reflected in the XML. We don't view Java coding and markup as mutually exclusive; in fact, we expect a majority of applications will do both; JDNC will encourage a sensible division of labor between the two. We hope to get the bits on javadesktop.org before JavaOne to encourage you all to come talk to us.

JDJ: How does JDNC compare with JSF? JDNC's stated goals include less round-trip data, while JSF is likely to mandate more round-trip data - is there a middle ground from Sun somewhere?
AF: Okay, I won't hide my bias. Excessive round-trips and associated page refreshes are an inherent limitation of HTML applications that resulted from jamming a square peg in a round hole - building GUI clients out of a document-viewing substrate. Nonetheless, HTML applications have become a major force in our daily lives and many have gotten quite good (Amazon paved the way). JSF is all about making those Web apps easier to build, which is a very good thing once you understand that doing it well is tricky indeed.

To borrow a term from Dr. Jakob Nielsen (www.useit.com), I think browser clients are well suited for the "ephemeral" use case where users perform limited tasks of a sequential nature. Rich, interactive clients deliver the tempo required by applications that are used intensively. Unfortunately, the user experience is usually not the driving factor in making the decision between the two.

But your question of a "middle ground" comes up a lot and I've been squinting to find it for some time. One potential integration idea is to build some JSF renderers that emit JDNC components as applets in key areas of the page to dial up the view interactivity, like providing a tabular data view that can be scrolled, sorted, filtered, and rearranged without page refreshes. Where this breaks down is when the user triggers an event that is routed back to the server and causes JSF to rerender the page. The applet (and data) must then be reloaded. Bummer. But software has amazing pliability, so I suspect we can solve these problems if we decide they need to be solved.

JDJ: Why has JSF focused solely on Web content? To me, being able to describe a working interface for all client models would be a huge benefit, as I typically develop Web applications but can see a valid use for some Web apps being desktop apps. So far, SwingML, XUL, thinlets, JSF...all are trying to do the same thing in different domains, which seems to beg for optimization.
AF: This is the holy grail of GUI development - the ability to define the UI once and have it magically map to the broad range of scenarios that face users today from small devices to browsers, to desktop apps, etc. The following is my personal assessment of why this won't work.

First, each scenario has distinctly different operational characteristics, such as screen-size, input device, memory capacity, network latency break points, etc., that require thoughtful reconfiguration of the user experience. For example, there's nothing more annoying than an HTML application that tries to act like a rich client - having the page refresh when the user makes a selection from a dropdown choice is an abomination of modern software. A decent client should leverage the network without obfuscating it.

Second, we are by nature visual creatures and are ultimately obsessed with having precise control over the bits on the screen. This almost always requires tinkering, which is tailored for the specific client technology. We'd never be satisfied with visuals that are generated or limited by the least common denominator.

Ranting aside, there is definitely room for significant sharing of some of the nonvisual bits, such as data models, validation, business logic, and application behavior. JSR 227 (data binding) promises the requisite data-binding scheme to support this and we're counting on Oracle to see this through [in the meantime, data binding will be a major feature of JDNC].

JDJ: Since I've brought up Swing...in the JDNC document, you mention some things in Swing as being nontrivial. Given that most Swing interfaces certainly don't seem to leverage what Swing can do (or don't leverage it well), do you see Swing improving in ways that would change that? Do you think Sun will ever revamp Swing's documentation to the point where the average Swing programmer no longer shrugs at "Swing's" poor performance? (I quote "Swing" there because it's my opinion that programmer education is the problem, not Swing.)
AF: Let's nail this right here. Due to tremendous efforts by the Java 2D, AWT, and Swing teams, and the kindness of Moore's Law, Swing performance is no longer a valid excuse for not using Java on the client. Thanks to Chet Haase and the Java 2D team, 2D will continue its trend to rely more on the graphics hardware acceleration. Swing's lead, Scott Violet, did work in 1.5 to reduce Swing's memory footprint somewhat. There are a bunch of creative discussions going on with members of the VM team on improving startup. I use a number of Swing applications daily on a three year old laptop and performance is just not a problem.

Now, one consistent and fair criticism is that it's harder than it should be to write a performant Swing app, which leads right to the issue currently burning holes in my laptop. How do we make Swing more tenable to a broader range of developers? We have to make it easier to approach and ensure developers can achieve better results with less effort. Swing is indeed broad and fine grained. This was intentional. We didn't want to limit the kinds of GUIs that could be developed in Java.

It took us awhile to realize that while we get twisted pleasure out of writing the threading code to load data into models asynchronously, 99% of the world does not. It's quite reasonable to simplify these common or difficult tasks by layering APIs (like JDNC), but we also need better tools and documentation.

One theory I'm still trying to prove is that our monstrous Javadoc is an issue. There are indeed more methods on JButton than there ought to be, yet we should be able to emphasize more clearly in tools and documentation the two or three that developers really need. Javadoc is the reference manual, yet I suspect it's also relied upon as a programmer's guide. I definitely use it that way - it annoys me when I also have to download a pdf spec to figure out how to use an API.

JDJ: As a corollary to the previous question, are the new technologies coming out of Sun prioritizing documentation and education? How much are they doing so, or are they focusing on the technology alone?
AF: Our priorities are clear: simplification and ease of development. Documentation and education are obviously large components of that, but it feels like we could do more of the latter. Our competition is very good at that.

JDJ: Will JDNC follow the JavaBeans component model?
AF: Yes. As much as possible, we're trying to make Swing functionality accessible through the beans patterns. For example, in our high-level table component, you'll be able to configure column rendering (colors, alignment, etc.) as bean properties without having to understand Swing's underlying CellRenderer mechanism.

JDJ: JavaBeans are used as a server-side component model, whereas they began life as a client-side tools API (with things like property editors and customizers). Are there any moves to embrace more server-side declaratives, or move toward the metadata model coming in 1.5?
AF: I believe that JSF has some facilities for managing beans in the Web tier. I recommend checking out the specification for details.

JDJ: As a corollary, how do the changes coming in 1.5 affect current designs?
AF: Version 1.5 is the most exciting Java release in some time. It's my personal misfortune that the current version of JDNC must run on 1.4.2, leaving me little time to play with 1.5 features directly. You all probably have more experience than I do in using 1.5's generics and autoboxing at this point! Unfair, but true.

In Swing, the new "Synth" look-and-feel will enable a whole new way to customize the look of an application without touching a line of code. This was part of the original vision of Swing - it just took us seven years to get to it. With 1.5, developers can skin applications without knowing anything about the pluggable look-and-feel (plaf) packages because the visual elements of the GUI can be configured in XML. Now we just need the tool that lets graphics designers, rather than engineers, create the skins.

For JDNC ,we're looking forward to leveraging Swing's new table printing, Java WebStart enhancements, the Xerces parser, and WebRowSet.

JDJ: How do you see Swing and SWT interoperating in the future?
AF: The AWT team made some changes in 1.5 to better support the hosting of Swing components within SWT (and Eclipse). It would be nice if they could be mixed and matched more freely; however, my understanding of the respective architectures is that this would be horrendously difficult without incompatible changes on one or both sides.

In light of Java's real and very mean competition (.NET and what's coming behind it), the last thing Java needs is a toolkit war. I've been there before - it's a complete waste of time. Our competitor gets great joy out of watching the infighting within the Unix community. Let's not go there with Java.

JDJ: With the LayoutManager2 interface the constraint object is passed as an argument to the container's add method. Why is the constraint not a property of java.awt.Component? Right now the only way to change a constraint is to add and remove the component.
AF: This does seem like an oversight that needs to be fixed. I'll plead the case with the AWT team.

JDJ: Are there any plans to make AWT and Swing interoperate better? If not, are there any plans to add Tree, Table, and TabFolder to AWT because this would go a long way toward satisfying the needs of people who want Swing's power coupled with native components?
AF: AWT and Swing interoperate fairly well as they share the same component model. We do have plans to make the heavyweight/lightweight clipping issue go away, hopefully, in the release subsequent to 1.5. We don't, however, currently have plans to build peer'd components for Tree, Table, etc. Look-and-feel fidelity is a big priority for us and we'll always be investigating ways to improve it, but likely in the context of the Swing components. However, the underlying platforms do evolve and we'll periodically reevaluate the best way to achieve fidelity.

JDJ: Do you find people at Sun have given up on Java on the client? You moved to JSF; is this because the focus went onto the server? Is the client coming back just hype or a reality?
AF: As with anything it's all a matter of perspective. You'll find a few people at Sun whose view is that Web clients are all that matter and Swing clients don't exist. Our team, on the other hand, gets daily requests to showcase Swing applications on Swing sightings and are noticing a boost in Swing development, which is backed up by a number of independent developer surveys. I moved to JSF primarily because I wanted to learn something new and I wanted to understand the EE world. I gained a fresh perspective from that experience, and it has helped drive my current fever to make rich Java clients easier to build. And I can spell X M L now too.

Who cares what I think, or what random Joe from org XYZ thinks. What matters is what the person in charge thinks. I can tell you that Jonathan Schwartz (Software EVP) "gets" that rich clients on the desktop are critical to Java's and Sun's long-term health. The client is definitely back and though Windows will likely remain the dominant desktop, we believe an increase of Linux and OSX desktops will make Java's cross-platform benefit even more relevant now than it was eight years ago.

We are looking out to where Java clients should be 3-4 years from now and plotting a steady course. There are big challenges and tremendous possibilities, given where graphics hardware is going. Resolution independence and better GUI/graphics integration are just a couple examples of crucial themes.

JDJ: There does not seem to be a "global API architect" over the entire Java API. Will Java APIs ever get a thorough review by such a person/committee? If so, when? If not, why not?
AF:There are definitely some very distinguished engineers in high places who are in charge of tracking, reviewing, and guiding our progress. You might see these guys giving the technical keynote at JavaOne. :-) The JCP plays a role here too - it's not just Sun, despite what the buzz on Javalobby says.

JDJ: You talked about the JCP and some of its good points and bad points - how are they addressed by the 2.6 release? And is JDNC going to be part of the JCP? (If it is already, what's the JSR number? If it isn't, why not?)
AF: JCP 2.6 introduces a number of changes that are a huge benefit to the public Java community, as well as the spec lead. First, the change that makes the first spec draft available to the public, rather than restricting it to the "JCP Community," will go a long way toward ensuring JSRs stay on track to meet the needs of the developers. Often expert groups are weighted on the geeky side, which doesn't always align with the practical priorities of the public. In addition, the change to encourage the first draft to go out with more "tbd" sections will enable expert groups to get to a first draft (and hence public feedback) much more quickly. Really really good from the perspective of an x-spec-lead - shrouding the JSR in secrecy felt like a burden to me.

JDNC is not currently being developed under the JCP. Once we get it out and in the hands of the development community and you tell us it's solving an important problem and should be standardized, then we'll definitely go there. But as I stated previously, I don't think the JCP is the place to do design from scratch. JSRs should be about taking something that exists in some form (however rough) and refining it for standardization. Rest assured, JSR or not, you all will have the opportunity to help shape JDNC because it won't succeed until it makes your development lives easier.