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.

A fighter pilot by day and a professional Swing developer by night. Meet Mikael Grev as the interview series on Swing, RIA and JavaFX that started with Amy Fowler continues.

Tell us a little bit about yourself.

I’m a geek and a fighter pilot. A strange and peculiar combination, I know, but it is true nevertheless. The duality was there from the beginning, playing Ice Hockey six days a week (against Peter Forsberg and Marcus Naslund no less) and coding demos on the Commodore 64/ Amiga the rest of the time.. My day job is in the Swedish Air Force, where I am an instructor on the Gripen fighter aircraft. All other time I run MiG InfoCom AB, a small consulting company. Married to an understanding wife, obviously no children. I would be surprised if your audience was interested in my military carrer, so I’ll leave that be :). When it comes to coding I have created Wing, a flight planning, coordination and evaluation system in use by the Swedish and Danish Air Force. I have also created MiG Calendar (and the site) which is the best selling Java component at the largest online reseller, ComponentSource. MiG Layout is my latest project. It is a FOSS (BSD) Layout Manager for both Swing and SWT that promises to put the fun back in hand coding GUIs… I am also quite proud of MiG Base64. Very geeky but fun for a performance freak like me.

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?

In general, pretty well. I find the famous comparison to a instrument panel of a Boeing 747 particularly amusing, and accurate. If you know what you are doing it is extensible to the extreme. As a newbie, however, you can find yourself spending hours doing the simplest of customizations. The other frameworks are generally simpler and less configurable. Either what you want to do is easy or not possible at all. Much of the complexity in Swing comes from the IMO bad architectural choice to extend the AWT base classes for the Swing components and the lack of properties.

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?

In Swing it is very easy to write simple components but very hard to write complex ones. Especially those that interact with other components during design-time. The support for having non-trivial properties is a nightmare and I have seen few other components than MiG Calendar that actually bothers with complex property editors. The reason is that the JavaBean spec is still at version 1.01 and has never been revised. There is a lot of trial-and-error when touching the outer parts of the spec since it is written in a very loose and open ended way. The problem with this flexibility is that it is interpreted in different ways by the different component container (IDE) vendors. Flexibility is often good, but here a more pragmatic approach would have been better, in retrospect. Since I have worked a lot with Swing, writing the actual components was not the hardest part, that was to make them work properly in all the IDEs. Especially the code->deploy->test-in-IDE- workflow is painful, time consuming and error prone. Without JFormDesigner I don’t think I would actually have made it.

JSR-273, where I am on the Expert Group, set out to firm up the JavaBean spec and provide for a better interface to components, especially under design-time. Unfortunately Sun was not interested in driving it to finnish. My conclusion is that Sun is not interested in a Swing component market.

In short, complex components are time consuming to create, hard to test in its target environment, and without a good channel to sell it. I also miss a good way to support licensing of the component within the IDE. VisualStudio, for instance, has direct suport for this.

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

I have mixed emotions. Another layer? Hiding something under another layer is seldom good, unless you make that layer so darn good that you never have to see the plumbing beneath. If Sun release it prematurely, or force the developer to jump down to the Swing level all the time, it can turn ugly fast. Sun has little goodwill they can ride when it comes to desktop matters, JavaFX better be perfect when released or the complain-a-lots will blog it to death.

It is paramount that all demos coming out of Sun looks absolutely stunning. The need to be at least as good as the Silverlight and Flash/Flex/Air demos, probably even better since they are the under dog. When looking at The new JavaFX site I’m uncertain that the Sun hired designers are up to snuff. At least to me it looks, well… you know… but taste differs.

I would probably have put my money in a non-backwards compatible complete Swing overhaul (called SwingIT!) where real properties, translucency, animation, binding and all that fancy stuff was built in from scratch. On top of that I would have built the tools that the designers could use. I sometimes wonder who JavaFX Script is for? Designers won’t touch it for sure and I don’t feel like I as a Swing developer would gain anything, except maybe for prototyping or small cool effects applets (where Flash is king anyway).

What worries me the most about JavaFX is that they are still using the really, well… quality challenged… Swing layout managers. Primarily not because of the actual layout managers, but because the JavaFX architects don’t seem to understand what the the real problems are. Even now when they have the chance to start with a clean slate, they start new with old stuff that never worked that good. But… Time will tell. Maybe I’m just getting old and don’t want my Swing magic wand to loose its swinging power. :)

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

To be honest I don’t know. Probably. Since it hasn’t been released I have too little information about the work needed to make a business decision. But if our customers want it, or JavaFX takes off like Sun think it will, I will do it for sure. I have been working a lot with GWT as of late and I actually like it, a lot. One cool, very AJAXy, interactive charting component, coming up!!

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

I get this question a lot and I never know what to answer. Or maybe more accurately, there is no short answer.. If you have good developers that have the time to put themselves properly in the know about Swing it is a good toolkit to use. Even more so if the app really needs to be cross platform. Most of Swing’s old problems are gone now. Performance and appearance have reached the level where they are no longer a problem. Though you can never just throw Swing at a large team of developers and let them have at it. Disaster would follow. A Swing project needs to be properly researched in advance to keep clear of the cavets. For instance, if you start using NetBeans and Matisse, which are both formidable tools in themselves, you have forever locked your team into that IDE when it comes to the GUI, and they are smarter than I am if they can alter the created GUI code by hand.. With proper research and initial study Swing can be recommended.

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

Yes I would. MiG Layout would help a lot of Java developers create good looking GUIs without them even thinking about it. White space and such are just handled automatically. Having MiG layout in the JDK would make it available to millions of developers compared to maybe 1% of that if it is kept outside as today. Only a fraction of the Java developers actually makes the effort to search the net for alternatives. Some don’t because they expect the best of breed to be included in the JDK and some because of the extra external dependency it would bring to the project. MiG Layout is now #14 at the TOP 25 RFE list and climbing fast. I know of no other official way to influence Sun in these matters, so why not cast a vote or two on it? (or three..)

Is there anything else you would like to add?

Pulling 9G:s I look just like my grandfather and my heart looks like a banana. ;)

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.