This year’s JavaOne placed a significant emphasis on client Java. The name Amy Fowler should ring a bell for anybody who ever delved into the intricacies of Swing internal implementation, and she graciously agreed to answer a few questions that i had after attending most of the desktop track sessions.

Tell us a little bit about yourself.

A love for both drawing and math is what drove me to major in computer science at Cal Poly in San Luis Obispo. However, my passion for coding didn’t start until I discovered graphics and UI programming about the time X11 was battling NeWS on Unix desktops (anyone remember that famous t-shirt with the race car rendered half smoothly in NeWS and half pixelated in X11?) When Java debuted in 95, the only thing I wanted to do was work on its UI toolkit. I joined the Java team in late 95 and after a painful year of AWT hacking and toolkit wars (remember IFC? Bongo? WFC?) we snuck lightweight components into JDK1.1 and started building Swing. Except for a one year hiatus in the web tier working on JSF (where I couldn’t get over not being able to draw on the screen) I’ve spent the last 11 years working on Swing or related projects.

What is your current position and responsibilities in Java client group?

I’m a senior engineer in the Java Client Group. The team hasn’t let me touch the Swing source in a few years, but I still consider myself a toolkit engineer. I recently built a new demo, SwingSet3, to showcase the Nimbus look and feel in Java 6 Update 10. SwingSet3 is an open source project and it’s built to support 3rd party look & feels and demos, so I’d welcome outside participation. I hope to see the Substance look & feel there soon :-)

JavaFX seems to be the new direction of client Java. What are the recommendations of migrating medium and large business applications, and should they consider porting to JavaFX at all?

In my experience in working with enterprise developers, there is a very rational and grounded resistance to jumping to anything new. So caution is wise at this early stage. Though it’s great fun to render multiple video feeds into hundreds of translated, animating graphics nodes, most business app developers are worried about much more basic problems, like managing views into large data sets and validating forms data. These things will be doable from JavaFX script, as it has access to the complete Java platform, but patterns and mechanisms are still being worked out. In fact, it should be possible to take a well-architected Java application and migrate only the GUI, leaving much of the underlying Java business logic in-tact. So longer term I definitely see value in evolving larger apps to use JavaFX script, as the benefits of accelerated GUI development will apply there, just as it does to slick visual ware.

What is the target audience of JavaFX? Are you looking at Swing developers, at RIA crowd (Flex / AIR / Silverlight), or perhaps at the wider Web community?

There have been questions around our target audience for both JavaFX “in general” and the JavaFX Script language specifically. In terms of the general target audience, we obviously have to focus initially on meeting the needs of a specific community, which is the RIA crowd (is anyone else tired of acronyms?). They are clearly less resistant to trying something new, especially when it speeds up development and is built on Java, which has always been about the internet.

But longer term, how many applications won’t be rich internet applications? Increasing graphics hardware acceleration is enabling the trend towards more beautiful and fluid interfaces. Ben Galbraith highlighted this point in his excellent
User Experience JavaOne talk when he pointed out that user expectations have now been raised beyond just usability — they now expect to be wowed (recall Maslow’s Hierarchy of Needs from Psych 101). It may be that consumer applications are leading this charge, but in the end we’re all human beings and there is no reason why we shouldn’t feel as pleased with the applications we use at work as with those we use at home. And note that “beauty” encompasses both aesthetics and purpose.

So how do you get a beautiful application? You have it designed by people who understand visual design and usability. Period. Karsten Lentzsch once made a great point that “finding the design” is really the hardest part of building
a GUI. And up to this point, the Java platform has been aimed at developers, most of whom couldn’t “find” a design if it landed on their MacBook Pro. So we have to provide a paradigm in Java which enables designers and developers
to work more seamlessly in constructing beautiful applications. We believe that JavaFX script, in conjunction with existing designer tools (Photoshop, Illustrator, etc) and development tools tailored for building GUIs, is how we’ll get there.

Now to comment on the target audience for the JavaFX Script language.

It’s really different from Java and THIS IS A GOOD THING. For defining visually rich user interfaces, it has some major advantages over Java:

• declarative syntax (without XML; no offense to the XML community, as XML has its place, but its verbosity is simply noise in a hierarchical GUI description)
• first-class functions for callbacks (no more writing of anonymous inner classes — the JFX compiler handles those gory details)
• expression-based binding (this is the power drill for GUI development; once you use it, going back to the hand drill is painful)

I’ll confess that I didn’t want to like it at first (felt a little like I was cheating on Java), but after I got over the hump of learning to declare what I wanted, rather than coding procedurally, it became quite addictive, especially binding. But don’t take my word for it; try it out yourself before you render an opinion.

Do we expect designers to code in it? Not any more than they currently code using JavaScript or ActionScript. Most of them will continue working visually with design tools, but if they had to make simple edits to JavaFX Script, that’s certainly doable. I will add that there’s a real geek component to JavaFX Script with sequences and bound functions that will appeal to the more sophisticated scripting programmer and make for some fun puzzlers.

There are quite a few features baked directly into the language such as binding, animations, effects and retained painting. While Swing code is pretty straightforward to debug, it would appear that debugging these JavaFX features requires some cooperation from the IDE developers. If this is correct, are you working with Eclipse, IDEA and NetBeans in this area?

IDE support is paramount, especially since JavaFX script is a completely new syntax and as you point out, has language features (such as binding) which will require special debugging support. The upcoming SDK will include a NetBeans plugin and I believe the popularity of IDEA and Eclipse will drive the creation of associated JavaFX plugins, either by Sun or 3rd parties.

With the comment about Swing code being straightforward to debug, I can’t resist putting in a plug for my favorite discovery at this year’s JavaOne: SwingExplorer an application that helps visually debug Swing by inspecting the containment hierarchy and stepping through paint operations. Our team always dreamed of building this but never found the time. Thank you, Maxim Zakharenkov.

We don’t see a lot of mature and professional third-party Swing component suites, especially compared to Delphi, .NET or even Flex. What are your thoughts on this subject?

We might not have the quantity of 3rd party component suites as other frameworks, but we certainly have a few very high quality ones: JIDE (David Qiao) and JGoodies (Karsten Lentzsch). And there is SwingLabs, which has a great extended component suite, led in heroic effort by Jeanette Winzenberg. There are also numerous popular 3rd party layout managers: FormLayout from JGoodies (along with JFormDesigner tool), and MiG Layout to name just a few.

Swing suffered incredible bad-timing in that just as we delivered its first release (late 90’s), JSP and web interfaces became all the rage. By the time folks realized every single application didn’t (and perhaps even shouldn’t) live inside HTML and the browser, Swing wasn’t the hot new thing on the block anymore. However, if you talk to the purveyors of the above frameworks, you’ll hear that their business is booming.

What would your recommendation be for third-party component developers? Should they wrap their components with JavaFX classes?

3rd party component developers should absolutely provide the appropriate JavaFX script wrappers so that these popular, seasoned components can be leveraged as first class script citizens using attributes, binding, and functions. The wrappers should be thin and so this shouldn’t be difficult. There may even be room for auto-generation mechanisms if the components are well behaved JavaBeans (which Swing components aren’t; sigh).

Recently a lot of JVM languages (such as Groovy, JRuby, Scala and Jython) have started using Swing as a “UI virtual machine”, using the same approach as JavaFX in providing more succinct and readable dynamic syntax for building user interfaces. Is this the future of Swing, with the new UI ideas and functionality developed in the dynamic languages?

There has been lots of internet buzz on this topic post-JavaOne. Many fear that we’re abandoning Swing and associated efforts (App Framework & Beans Binding) in favor of “everything FX script”. Not true. We realize that one size will never fit all and that this language diversity on top of the VM is only good for Java. And this, in my opinion, is the genius behind JavaFX: we are migrating to the next generation client paradigm by leveraging our existing stack rather than throwing it out and starting over. Project SceneGraph enables us to finally combine 2D, 3D, media, and animation with a stable, mature, well-rounded GUI suite (Swing & partners). Over time we’ll see more GUI components constructed from purely scene-graph nodes, but that will take time (it’s harder than you think).

In terms of evolving the platform, there will be times where we should innovate in the Java APIs, as this stands to benefit everyone using the platform, yet there will be areas where it’s wiser to focus on innovating in the more dynamic script layer. The latter will be particularly true when the script language features can play a key role in the innovation. The perfect example of this is in the simplified FX script component suite, where attributes, functions, and binding make it much easier to create a simpler API. I once tried to create ease-of-use Java wrappers around Swing (remember JDNC?) and the improvement was marginal at best.

What would you consider to be Swing’s weak points, and how are they addressed in JavaFX?

I see two primary issues in Swing which JavaFX seeks to resolve:

1. If you code in Swing, you have to be somewhat of a plumber. I’d argue that Swing is necessarily complex, as are other toolkits in its class, which strive to solve the general case of UI construction. However, features in JavaFX script (again, declarative syntax, binding, functions) result in streamlining GUI assembly because you declare what you want and the plumbing is handled under the covers by the compiler. Anticipating the usual counter point, some will argue that you’re better off if you understand the plumbing, as you’ll be able to more easily debug problems. Well, I say that most developers don’t want to be plumbers; they just want it to work and provide sensible feedback when there’s a crack in the pipe.
2. Swing components don’t live in the 2D coordinate space. I was a NeWS fan, so this has always bothered me. And although you can implement animated transitions and visual effects using clever imaging tricks, it requires a high level of expertise and it’s difficult to tool. The new SceneGraph API changes all that and is the underlying technology that enables the cool, animated GUIs you see in JavaFX. Swing components can be used as 2D nodes in a scene graph, allowing affine transforms and composite operations to be applied. Building on that is Chris Campbell’s Effects Framework, which encapsulates the most common visual effects (drop shadows, blurs, lighting, etc), which is my personal dream come true.

Anything else that you want to tell us about Swing, JavaFX or client technologies in general?

JavaOne tends to get caught up in whatever is new and sexy. Yet my favorite announcements (and the most under-sung, in my opinion) were around Java6 Update 10:

• Java Kernel
• Next Generation Java Plugin
• Deployment Toolkit
• Nimbus Look and Feel
• Java Quick Starter
• More graphics acceleration for Java2D
• Shaped and translucent toplevel windows

See Java6 Update10 Overview for details.

After all, if we don’t resolve these issues, it really doesn’t matter what else we do.

Here are some Swing links that you might have missed during this week:

• This subject seems to come up every now and then over the last couple of years. Supporting CSS in Swing has been mentioned in Ben Galbraith‘s presentation at last year’s JavaOne, Eitan Suez‘s JMatter has a CSS module in it, and the naming conventions for styles in Nimbus is very similar in concept to CSS. Now, there is a new project on SourceForge led by Angelo Zerr and Jawher Moussa that aims to provide a toolkit for declaratively building UIs. The Tk-UI project has, among the rest, an engine for applying CSS styles on Swing and SWT components.
• Danno Ferrin has published the Groovy Twitter client from his JavaOne session. The entry has a link to the WebStart demo and the sources. The application itself uses the Nimbus look-and-feel if it is available.
• A new section has been added to the release notes of the new plugin in JDK 6u10. It describes the functionality of dragging the applets to the desktop. Unlike the existing lifecycle methods defined in the Applet and JApplet methods, the relevant APIs are not APIs at all. So, pay very close attention to how you name your methods, because the compiler and the IDE won’t help you.
• Dmitry Bondarenko has written an official guide to the translucent and shaped windows in 6u10.  Not much in the way of new information for those readers that saw my earlier introduction entry in February, the follow up on soft clipping and per-pixel translucency entry in March, and the java.net article on more advanced UI tricks. However, having the official Sun documentation gives a more prominent status to this functionality, raising the predictable question from Eric Burke – is it, or is it not a new official API?
• Alex Ruiz points to the new NetBeans plugin written by Geertjan Wielenga. This plugin wraps the FEST-Swing UI testing framework and allows easy creation of UI tests from within NetBeans.
• Christopher Deckers has announced the new release 0.9.5 of DJ Native Swing project that aims to provide integration of native components, such as web browser, Flash player, multimedia player and HTML editor into Swing applications.
• Finally, Jonathan Schwartz lays out his plans for JavaFX. This is the first (at least in my memory) time that he is talking explicitly about Java on client.

This is the final part of the series on one-man open source projects. In the previous entries i talked about the different facets of the issues that face single-developer projects:

• Development and staying passionate
• Maintenance and staying focused
• Promotion and staying committed

There are a lot of big projects out there with dozens of active developers and hundreds of people actively involved behind the scenes. Sometimes, developers of these projects have the luxury to concentrate on what they love to do the most – coding. However, the terms such as steering committee, constitution, incubation and governance models do not apply to the vast majority of the open-source projects. Such projects frequently languish because their developers fail to recognize that all those menial and tedium tasks are crucial for the long term health of their projects.

Sometimes, the solo developer behind a fledgling open-source project has an unreasonably high level of expectations from the target user sector. This frequently leads to frustration from low number of downloads, lack of interest from the blogosphere and may even result in venting your anger against the competing projects in public forums, mailing lists and blog comments. While being the best in your field is an understandable goal, i would advise focusing on other aspects instead.

Is being the best a goal in itself? How about admitting the following three simple things:

• You know you’ll make mistakes
• You’re ready to learn from them
• You hope to not repeat the same mistakes in the future

This way, you will not be afraid to make a mistake, not be afraid to admit a mistake and be very quick to fix one. And in any case, what are your chances of being the best? Next time you attend a technical conference, look around you. What are your chances of being the smartest guy in the room? What are your chances of being the smartest guy at the conference? What are your chances of being the smartest developer using your favorite language? What are your chances of being the smartest guy in the world?

If you have a blog, if you have your own open-source project, even if you comment on somebody else’s blog – you want to be heard. If you’re open to comments, bug reports, enhancement requests and a genuine two-way conversation with your users, you will be surprised at how much you can learn from them. And if you have the ability to cut through the complexity, distill chaotic flows into a clean API and communicate without condescension, they will come.

P.S. This series was originally conceived as a session for this year’s JavaOne and OSCON conferences. Even though the reviewing committees were not overly impressed, i do feel that it is an important topic. You can download the full slides in PDF format. There are no absolutes. This is what works for me.

If you write it they will come. Open source software has thousands of eyeballs monitoring it for flaws. Let the code speak for itself. The code is the best documentation. Haven’t we all heard this before, and haven’t we all had this type of wishful thinking? Alas, the harsh reality of hundreds of thousands of languishing open-source projects is in a stark contrast with the rosy promises and expectations that you might nourish when you start your own one-man open source project. Your pour countless hours into ??????developing and maintaining your project, only to see the weekly download count stuck at single digits, and community at large blissfully ignoring your labor. There is only one thing that you’re missing, and for some it might evoke an uneasy association with “those marketing suites”. In a one-man project, you are the developer and the maintainer, but you are also the tech pub, promoter, evangelist and marketer.

You need to stay passionate to continue developing your project even when nobody comes. You need to stay focused to maintain your project and properly prioritize different tasks. When it comes to promotion, you need to stay committed.

Most of the developers are introvert by nature, preferring to let the code speak for itself. The only problem is that there is too much code out there, and your potential users need to be gently and constantly reminded just how awesome your code is. Obviously, you’re not one of those “marketing suites”, and your target audience is your fellow developers. All you need to do is to think about how to “sell” your project to a guy just like yourself. That would mean highlighting the capabilities of your project, objectively comparing it to the competition (even when you’re lagging behind in some areas), not digressing into marketese and buzzword speak, and, perhaps most importantly, constantly staying on the radar.

The last part can be a turn-off for a coder. If you’re a coder, chances are that you don’t like to write documentation. Also, chances are that you don’t feel the need to discuss the reasons behind a specific design / implementation decision, especially if you’ve built yourself a little ivory tower. Chances are, even, that you don’t feel the need to create and maintain a comprehensive set of test applications that showcase all your awesome APIs. Finally, chances are that all you want to do all day long is to just write the damn code. Indeed, promoting a project takes a serious commitment, especially in the light of all the things that you need to do to grab peoples’ attention and don’t let go.

I have already mentioned this in the previous entry – new features should be the last item in your priority list, just after the documentation. I’ve also mentioned the catch-22 situation – nobody reads the documentation, but you must have it to answer the users’ questions in any case. It is your fault if the users need documentation to understand your library, and it is your fault if the documentation is too complex to immediately find an answer. However, the documentation is the “looks” that sell. Poor documentation or lack of thereof indicate a project that does not place enough value on users’ time. Documentation generated by Maven-like tools may fool the users a little, but the end result is an even more disgruntled user that was tricked into thinking there is documentation, when there is none.

Take a break from your frantic coding and ask yourself a simple question – how easy it is to understand your library for a user that has absolutely no knowledge in this specific area? Do you have a simple and intuitive index to guide the novice users around the basic concepts? Do you have a quick start guide? Is it kept in sync with your latest release / development version? Do you have simple examples that show how to use each single API method? Do you have in-depth tutorials for advanced users? You might be a star coder that can download a new library, load the sources in your text editor and start using it right away, but most of us are not. Do your project a favor and document every single thing that you can think of. And by the way, every time you get a question on “how do i do …” in a project forum or mailing list – it is your fault, even when it is documented.

Developers prefer to develop, especially when we are not confined by the project management to do all the tedium tasks. However, “the source code is the best documentation” is a sorry excuse, especially nearer the end of the release cycle. Instead of postponing the documentation until all the coding is done (which never happens), just spread it across the entire release cycle. You need to consider it as a vital part of the project tasks, and always think from the perspective of existing and potential users. Do not concentrate on how much you hate writing documentation. Instead, just do it.

The same principles apply to the test applications. While you should have a few big test applications that showcase your library as a whole, you should also write a very simple and complete example for each one of your public APIs. Keep them always in sync with the latest release (or the latest development version), interlink heavily and organize in an intuitive manner (grouping by business / related functionality).

Finally, have a blog. Get into the habit of writing 2-3 times a week. You might think that you don’t have anything valuable to say, but you will be surprised. If people want to download your code, they will also want to read your blog. It doesn’t have to be exclusively about your project. On the other hand, it doesn’t have to be about your favorite types of food. Once you get into the habit of writing, it will be much easier to continue doing so, even if English is not your native language. This might even come handy when you’ll need to write documentation at work. When everybody else is unhappy, you just cruise through and get to writing the code before they do.

There is a pleasant side effect when you blog about your project – from time to time you will get feedback from readers that are not users of your project. They might as well be potential users if you pique their interest, and they might provide very valuable feedback even when they have no intentions to be your users. You should never dismiss such feedback just because they are not your users. On the contrary, you might see why they do not intend to become your users, and gain some knowledge about your project, your goals and your vision.

The last entry summarizes the discussion.

The image is available under Creative Commons Attribution license from the following flickr.com stream:

• Ants on a rope by wwarby