A prolific blogger, a frequent presenter at conferences and a tireless advocate of Groovy. Meet Andres Almiray as the interview series on Swing, RIA, JavaFX and related topics that started with Amy Fowler, Mikael Grev, David Qiao and Chet Haase continues.

Tell us a little bit about yourself.

I’m a software geek who prefers Java/Groovy to do his work, I’ve been hooked into computer graphics since college (being able to use both SGI workstations and PowerMacs helped a lot), which also explains why I picked Java since the early beginnings. But life has a way to move you to places you didn’t expected at first, so I have my share of years behind server development and web applications (PHP and Perl included, yikes!), I even managed to get some ActionScript somewhere in between. These days I’m back to desktop, my day job being mostly related to Swing development at Oracle, my free time devoted to Groovy related projects like GraphicsBuilder (a Java2D builder) that complements SwingBuilder, and other open source related initiatives.

What do you think about Sun’s new direction of client Java towards RIA space with JavaFX?

I think it is about time Sun really cared about the desktop, I’ve been waiting for something like this since Swing came out. The good news is that some AWT/Swing APIs will be updated, as we have seen lately non-rectangular, translucent windows are finally available, while at the same time new APIs have been added like project SceneGraph and JWebPane, smaller JRE and faster applets too. I gladly welcome all those upgrades. But I don’t buy it on JavaFX Script just yet, I have to admit I’m biased on this one being a Groovy developer, as almost everything that JavaFX Script offers I can do with Groovy, the only thing not possible (today) is binding to any expression, which I consider the sole benefit to switch over JavaFX Script, it is really that powerful. But who knows, nothing is set on stone, I might code real applications with it at some point in the future.

Over the last year we have seen a growing number of projects using Swing as a backbone for new UI scripting languages. This includes Groovy, Scala, Jython, JRuby and, of course, JavaFX. Should this be the future of Swing – relegated to be just a foundation layer?

Let’s face it, compared to those other languages Swing in plain Java is too verbose, which is perhaps why so many developers would rather tango with visual tools and code generators in the first place. I believe in polyglot programming, thankfully I’m not restricted to code in just one language to rule over all my applications. Swing as a foundation layer makes sense, but considering that some of those languages provide a way to enhance existing Java classes (even in runtime) you may bend the foundation to your needs.

What are Swing’s weak points, and how are they addressed in Groovy’s SwingBuilder?

Besides it being verbose because of the Java language itself, I would say threading, it is so easy to shoot yourself in the foot with threading issues, you have to constantly remind yourself in which thread your code will be executed. Groovy’s SwingBuilder addresses the first point with Groovy itself. With native syntax for List and Maps, property access on beans, safe reference navigation and GPath, closures and metaprogramming, you have a full set of new tools to code less while retaining the same behavior. The second one is explicit to the builder as it exposes a set of methods that deal with threading in a very simple way. Say you write an ActionListener, as you now all listeners are called on the EDT, in this case the handling code will perform a long task and update the ui when it finishes. The usual solution in plain Java would be to call SwingUtilities.[invokeLater|invokeAndWait] with a Runnable as parameter, which means you have to create a new class, even if it is an inner anonymous one. With SwingBuilder you could do something like this

Do you feel constrained by the internals of Swing?

I consider myself a regular Swing developer, so far I’ve never had the need to meddle with a RepaintManager nor other scary/gory Swing internals, I leave that to the experts like you.

Both JavaFX and Groovy’s SwingBuilder provide access to Swing components and full APIs. Is this a desired feature for migrating existing applications, or perhaps this access should be restricted to enforce a cleaner design and not add yet another way on top of all that Swing carries with it over the past ten years?

There is a slight difference, JavaFX Script relies on Swing wrappers, those wrappers give JavaFX Script better control on Swing components. On the other hand Groovy’s SwingBuilder uses Swing classes as is. Groovy is able to dynamically enhance (both at compile time and runtime) said Swing classes, if needed be, thanks to its metaprogramming facilities. In the end JavaFX has a thin layer of abstraction that may be used as an extension point (in the future) without needing to actually change any Swing class, while Groovy itself can be used at any time to extend those classes. Back on your question both approaches already add something on top of Swing in some way but they clearly do not restrict access in any way, I believe design in Swing can be clean, it just takes too much lines of code to get to that point.

What do you think about visual designers? Should we encourage their use for beginner developers, even at the price of hiding the API internals and creating possible maintenance problems?

Perhaps I’m old-school as I have always preferred VI/command line tools over IDEs and designers, but I would say yes. Let beginners use a visual tool to feel more confident while starting out, but at the same time encourage them to look under the hood and get acquantied with the generated code, so that they may understand it, and later be able to tweak it by hand when and where it makes sense.

What do you think about blurring the lines between business and consumer applications? Should a business application look sleek just because everybody else is doing it?

Should we all fall from a cliff as lemmings do? of course not =). I’m with Chet Haase on this one, snazzy and springy effects do not belong on a business application in most cases, but using animation as a feedback is a powerful tool, perhaps it is a glow effect on a button or a translucent dialog/blurred background combination to focus the user’s attention into a recent change or a part of the UI that requires interaction at that precise moment.

What are your thoughts on breaking compatibility to correct old mistakes and provide a better designed UI toolkit?

If it makes development and a reasonable (by reasonable understanding perhaps a ratio of lines of code to change mixed with the amount of testing that has to be done) migration path for existing applications for which source code is available I would say yes, go for it. I’m sorry for those people that would like to use newer versions of the JRE but remain forever in compatibility mode, compromises have to be made if you are willing to play with new toys.

Is there anything else you would like to add?

Don’t write off desktop apps just yet given that many have jumped into the web bandwagon. Webapps have been copying desktop apps since the very beginning, and now desktop apps are catching up, after all Ben Galbraith said a year ago “Web is becoming ‘desktopy’, Desktop is becoming ‘weby'” (or something close to that) and I believe he is right.

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

• Alex Ruiz has announced release 1.0 alpha2 of FEST-Swing library for functional Swing UI testing.
• Roman Kennke shows the first UI working on Jamaica virtual machine with OpenJDK.
• Alexey Utkin posts a few sample examples of geocoding with JDICPlus, including locators, mouse tracing and alpha mixing.
• Vladimir Ikryanov summarizes his experience with Swing Application Framework. Richard Osbaldeston has a particularly interesting and gloomy comment.
• Collin Fagan is working on the Java Tutorials project, and has a few new JTable and JTree code samples.
• Project Albireo has announced release 0.0.2 (alpha2). The goal of this project is to simplify the task of combining Swing and SWT components, and at first stage focuses on allowing seamless embedding of Swing component in SWT applications. A few code samples are available, as well as general installation instructions.
• Christophe Le Besnerais has published a very useful macro for searching Swing documentation in IE7 / Firefox.
• Jacek Furmankiewicz continues working on the SwingBuilder project, adding first support for validator logic.
• Finally, Dalton Filho has an interesting project that allows saving Swing windows created by Matisse (NetBeans UI designer) as equivalent wxWidgets windows in C++.

One of Substance users has switched from version 3.3 to the 4.* line, and is now missing his favorite Streetlights skin. Indeed, it has been removed about a year ago in version 4.0. This specific skin was never marked as officially supported, and the reason was simple – the old theming layer was not powerful enough to support a skin that mixes dark and bright colors.

It is difficult to design a pleasant skin that combines dark colors for overall controls and bright colors for active controls (selected, rolled over, pressed, armed). It is more difficult to implement such a skin in a programmatic way, and even more so to properly support animations. With usual bright colors you only need to animate the background fill while the foreground color stays the same (usually black). The dark-bright switch requires animating both foreground and background colors. Also, there are many corner cases that reveal themselves only with this specific combination. For example, using the same bright colors for both inner fill and outer border of a selected button results in a very fuzzy appearance. It is much better to use dark colors for painting borders of brightly-filled buttons.

As i have already mentioned, the new version of Substance (currently under development) as much more powerful theming layer. Now it is possible to bring Streelights back to life, this time with much better and consistent visuals. Here is a thumbnail of the test application running under Streetlights (click to see full size):

You’re more than welcome to read the code behind the Streetlights skin. It is available as part of the Extras pack.

Meet David Qiao, the founder of JIDE Software, as the interview series on Swing, RIA and JavaFX that started with Amy Fowler and Mikael Grev continues.

Tell us a little bit about yourself.

My software career started after I got a bachelor degree in computer science from Nanjing University and a master degree on the same field from SUNY at Buffalo. After “wasting” several years doing MFC and .NET stuffs, I finally found what I love to do and can be proud of – founding JIDE Software back in 2003 and working on Java/Swing and UI design. Since then, I am lucky to ride the new wave of Java desktop and drive JIDE to be one of the leading Swing components and services providers.

You’re writing open-source and commercial Swing components primarily oriented at business applications. How do you think Swing fares as compared to competing toolkits, such as MFC, Delphi, GTK, Cocoa, QT and others?

Swing lacks the basic out-of-box components comparing with other toolkits. It is rare to see a GUI toolkit that doesn’t come with a date chooser component, for example. Swing doesn’t have one. Swing also suffered from relatively more bugs and sluggishness, especially when it affects the basic functionality of a user interface. It didn’t come with a decent built-in GUI designer like Visual Studio or Delphi does. Swing would have been more successful by addressing these three issues early on. Even so, Swing still stood out among all the UI toolkits mainly because of its elegant design, cross platform availability, pluggable L&F and being part of core Java. Things are certainly moving forward in recent years on all three issues. More and more companies are choosing Swing as their UI toolkits. I just hope Sun doesn’t mess up again this time.

Other UI toolkits seem to have much larger variety of professional third-party component suites. Amy Fowler attributes this to the rise of web applications, but it didn’t seem to affect the market of Delphi and .NET components. What are your thoughts?

I believe consumer applications are the driving force for .NET components. What platforms are the consumers using? Windows, period. They don’t care about Linux or Mac (at least a few years ago). .NET is good enough for them. Swing is used largely in enterprise applications inside relatively larger companies. Many companies spent their own developer hours to make custom components and use them internally only. They have larger budget and have a longer release cycle so they can afford to make their own components. I bet this kind of thing will not happen in .NET for a consumer application as the release cycle is short and they just want to buy the components and get it done faster. So I believe this is the reason for large 3rd component market in .NET. I would love to see statistics showing the number and type of applications writing in each toolkit to prove if what I said is correct.

What do you think about Sun’s new direction of client Java towards RIA space with JavaFX?

Great. Technologies are merging. Microsoft introduces Silverlight to light up the web. Adobe introduces Flex to flash up the desktop. It is certainly making sense for Sun to introduce JavaFX to enter the consumer application market. It is a new market for Sun so it really has nothing to loose. However entering new market doesn’t mean giving up existing markets. Sun should continue investing in Swing. Swing is popular among enterprise applications and should be kept that way. I doubt large complex enterprise applications will use JavaFX any time soon. It will still primarily Swing’s market, maybe with some help from SceneGraph. Not even Flex.

Are you planning to wrap your components for easier consumption in JavaFX applications?

Absolutely. It gives JIDE a chance to enter the consumer application market, why not?

Can Swing be considered a premier choice for cross-platform UI development today? Would you recommend Swing for building large long-term business applications?

Of course. As I mentioned above, Swing is already used in many large complex enterprise applications. It is a perfect fit.

Would you want to see your products folded into the core JDK distribution, and why?

I would love to see it. Some of the basic features should be included in JDK. I had a talk at this year’s JavaOne where I mentioned the support for non-contiguous cell selection in JTable. Swing JTable is totally wrong when the cell selection is enabled. JIDE fixed this in JideTable. I would love to contribute the code back to Swing, and for free of course. There are many features or bug fixes in JIDE that I would like to contribute back. Why? Those are basic features that should be included in every UI toolkit. It is already a mistake that we had to add those features ourselves.

Is there anything else you would like to add?

We mentioned on our website that “Thousands and thousands of developers’ valuable hours are wasted on building the same component which has been built elsewhere. Why don’t you focus on the most value-added part of your application and let us build those commonly used components for you?” Believe it or not, it is true. Many developers wrote their own general purpose Swing components. Raise your hand if you do! I just want to take this chance to say, please use existing components if you can find one, from JIDE, SwingX, or any other open source or commercial component vendors. It will save your money, save your time and accelerate your application development. A healthy third-party component market is very important for any UI toolkits.