JDJ Industry Interviews
Java Trends - Exclusive Interview with Amy Fowler
Java Trends - Exclusive Interview with Amy Fowler
By: Joseph Ottinger
May. 5, 2004 12:00 AM
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?
JDJ: What do you see Java being like in the future?
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.
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?
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?
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.
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.)
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?
JDJ: Will JDNC follow the JavaBeans component model?
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?
JDJ: As a corollary, how do the changes coming in 1.5 affect current designs?
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?
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.
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?
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?
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?
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?)
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.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week