Swing, RIA and JavaFX – interview with Amy Fowler
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:
- 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.
- 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.
Related posts:
- Swing, RIA and JavaFX – interview with David Qiao Meet David Qiao, the founder of JIDE Software, as the interview series on Swing, RIA...
- Swing, RIA and JavaFX – interview with Mikael Grev A fighter pilot by day and a professional Swing developer by night. Meet Mikael Grev...
- Swing, RIA and JVM dynamic languages – interview with Andres Almiray A prolific blogger, a frequent presenter at conferences and a tireless advocate of Groovy. Meet...
- Swing, RIA and Sage browser – interview with Don DeCoteau A few weeks ago i have mentioned the Sage project, and it’s time for a...
May 19th, 2008 at 8:34 am
responding to questions on Swing, RIA, and JavaFX
JavaOne raised many questions for Swing developers regarding the future of client development and I’d like to take a first stab at answering some of them.
May 19th, 2008 at 12:01 pm
Java 6.10 only runs on PowerPoint. End user’s have a hard time deploying applets, it’s limited to 32 bit windows. Compare deployment http://www.onflex.org on the right side.
May 20th, 2008 at 1:15 am
Reading between the lines a bit but is she suggesting theres no good reason to continue using Swing here? i.e. The plan is to deprecate Swing to the low level plumbing and legacy support. Is this why nobodies currently supporting the Timing Framework, JSR 295, JSR 296 etc.. because they overlap with JavaFX functionality and adding these to Swing would compete directly with JavaFX adoption..?
As a long time Swing developer the things I don’t like about JavaFX is – it’s not Java. I don’t understand how it interacts with existing Java classes and Swing components. The lack of IDE support or rather support from my IDE and GUI Builder would be an issue, I need to understand if migration of my existing forms would be possible or even make any sense. I’m also concerted that the declarative scripting nature tends to encourage bad design practices of overloading the views with too much business logic. Is design and loner term maintainability being compromised in favor of ease of getting something on the screen ASAP? I have much the same feelings about Matisse and about every Swing tutorial that advocates extending JComponents though.
Some of the advanced Java Update N features bother me slightly as they’re only available for certain OS’es and browser choices. With the WebKit announcement this leaves me wondering what JavaFX is targeted at. Is it really ‘devices’ or the developer desktop? what ever happened to WORA?
As developers how are we supposed to take advantages of these new features for Windows and still support Linux or OSX for example? I’m not entirely sold on the “Swing is still being actively developed” line we saw last week. As those features were very much limited to projects that were started before JavaFX or features that JavaFX desperately needs. Theres no work being done on things like beansbindings or Swing Components that’d be a godsend to purely us dejected Swing developers.
In a nutshell is Sun pulling the same kind of stunt on Client-Side Java that Microsoft did on VB6 users? or is it more of a Yes, if it turns out to be a success and not a huge white-elephant.
May 20th, 2008 at 2:57 am
JavaFX was presented as something last year, now it is presented as a direct competitor to Adobe AIR and Microsoft Silverlight with the addition of upcoming JWebPane. I personally, do not see any wide adaption of AIR and Silverlight in industry at all. It is only used for pet projects from blog writers. Also, I do not believe a JavaFX script will get the much anticipated acception from the industry at all.
JavaFX will be just like the buzz Air has been buzzing around. It sound like a buzz and it will remain a Buzz. Adding a new level of dimension to the development with an addition of a new scripting framework will not get the much expected attension at all. JavaFX will be again shelved in couple of months just like it did last year after JavaOne.
Sun is wasting considerable resource just to confront Adobe Air and Microsoft Silverlight which unfortunarelt are not going to make the impact. As long as web is around, people will opt always for simple, established and widely accepted.
May 20th, 2008 at 9:04 am
if Java could have binding baked into the language eg. via properties – or alternatively netbeans could tool up bindings as if Java had such support – then together with declarative XML (again tooled up in Netbeans), one could enjoy the benefits mentioned ie. declarative composition of UI plus binding, using Java/Swing?
May 20th, 2008 at 10:48 am
I personally am not super keen on Sun creating a whole new language to add RIA capabilities, instead of investing into Java itself.
Many alternatives good have been taken, e.g. declaring the UI/binding in a separate file (like Silverlight with XAML) instead of forcing a whole new language. MS didn’t invent C#FX, they just used C#…it’s much easier to expand an existing language then to force a brand new one.
Also, XML is bad, true. But JSON used by JavaFX is hardly any better. It replaces XML’s verbosity with JSON’s closing bracket hell instead (multiple levels of nested {}}[]…you name it…I’ve seen it in every JavaFX code sample).
My little OS Java SwingBuilder project aims to do something like this, but by declaring the UI in a separate file defined in YAML format, which avoids both XML’s and JSON’s shortcomings.
http://javabuilders.org
I have not integrated Project Scenegraph yet into it, but UI declaration/binding is in there already…and the FX from Scenegraph will be added in soon. The bottom line is that 100% of the code stays in pure Java, just the declarative UI part is in a separate file.
May 20th, 2008 at 1:41 pm
Evanx has a point. JDK7 already has properties as language level features and closures on the drawing board. Both touted as JavaFX benefits. Wouldn’t a re-engineered Swing to use some of the last decades enhancements, collections, generics, annotations, properties (with jsr295 bindings) and closures be preferable to jumping the gun with a new language for such a nebulous requirement like RIAs now? (Actually fixing those bean issues and the awkward models or plain missing models choices and the embarrassing HTMLRenderKit would be on my wishlist for Swing too).
When Amy says Swing will be supported does she mean like AWT is supported in maintenance mode only? Except where features developed for JavaFX happen to be usable in Swing by virtue of their AWT<-Swing<-JavaFX layered approach. Or are they seriously suggesting they’ll continue to duplicate the most useful JavaFX features in Swing too? Personally my clients aren’t asking for translucent windows, drop shadows, animation nor drop shadows.
The interview also mentions JavaFX isn’t the first attempt at improving on Swing, we’ve seen JDNC come and go and there were other failed attempts at bindings even before JSR295 foundered. Losing CTO (Hans Muller) and two architects in Scott Violett and Chet Haase in the same year really cries out not all the development team shared the same enthusiasm for the latest approach. As the previous attempts failed how much faith do you expect us to now show for JavaFX?
May 20th, 2008 at 3:03 pm
All fair comments and concerns.
If you read carefully, you’ll note I did not suggest that everyone should jump to the FX platform; only that it has potential to accelerate GUI development on a broader scale longer term.
And I’m ecstatic to hear such strong voices of support for Swing, as we still have plenty of evolution to do there.
May 21st, 2008 at 4:15 am
Sounds like the funeral eulogy for Swing. You thank all the people who tried to make it better (but never had the slightest chance to get their improvements into an official release), then you close the lid, fire three rounds of salute, and lay it to rest. So Swing’s grave will be next to AWT’s grave, on the Java Graveyard Of Abandoned APIs, near the Synth PLAF, around the corner of the row of dead image and media APIs.
> If you read carefully,
> …
> we still have plenty of evolution to do there.
Yes you have, but the careful reader recognizes that you said “have to do” and not “will do”.
May 21st, 2008 at 7:27 am
Well, the Synth PLAF is hardly abandoned. I recall reading on JL that it was actually actively enhanced to make Nimbus work well. So, let’s not get too funeral-oriented here…and all of javaFX’s power is readily available via Scenegraph and beans binding…I know it is, since I am using it myself in pure Java.
May 21st, 2008 at 7:29 am
Hi Amy,
Thanks a lot for warm words about Swing Explorer. It is really pleasant to hear such things from Swing engineers. I’m planning to add some more cool functionality in near future. I hope that Swing team will use Swing Explorer and enjoy.
BTW It seems like I’ve seen you at JavaOne. You tried to destroy your Flex book copy received from Chet. Have you succeeded finally? :)
Maxim
May 22nd, 2008 at 4:30 am
“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.”
This is the divide between programmers and designers. JavaFX is not a tool for designers to create GUI’s, let’s be clear. A tool is an application such as Photoshop, or Flash. What we need is an app that allows us to build GUI’s visually, with JavaFX as the mechanism behind it.
May 24th, 2008 at 7:19 pm
Flex, Silverlight, and JavaFX are marketing languages. Are they good for enterprise users, developers, and stockholders? Most enterprise users care more about getting their jobs done in a right and quick way. If they want entertainment, they won’t like to get it in the offices. Can JavaFX entertain developers? You tell me. If users cannot appreciate what you have done with JavaFX, I then see no difference between Swing and JavaFX. Why not improve Swing? Make Swing simple and shining. Using Swing is really painful. Switching to JavaFX is a pain already. Sun has made a lot of mistakes. Don’t do it again. You cannot afford this time. Stockholders are watching. Will they get entertained with JavaFX? You tell me.
May 28th, 2008 at 11:43 pm
Sad state if Sun really is setting up the demise of Swing (as implied) – for some unproven technology.
I remember reading a year or 2 ago Hans Muller’s blog. He was all fired up about Swing officially
being the number one used GUI toolkit at the time.
That was really encouraging.
A mere 2 years later we hear of its possible end.
I invested over 3 years of my career in Swing – so it really does hit home.
Another thing is people keep saying, Swing is complex, etc. I do agree that it has a steep learning curve, as does hibernate, and any framework related to large scale apps. and enterprise software. Once you get the hang of
it though, things are pretty simple. e.g if you figure out how to framework Swing via Reflection as per Spring-Rich, Screens go up mighty fast.
Nice article though…
May 29th, 2008 at 9:21 am
Reports of Swing’s demise are greatly exaggerated.
Did y’all read the same article I read? “Business is booming” for partners. I see a lot of Swing and it will always be a natural fit for Java shops.
Swing needs to compete in the RIA market, and JavaFX is a step in the right direction.
All the flash is nice, but what people have been calling for for years (and have in these comments) are easier ways to build business apps.
Spike is right – Swing is great if you can get all the wires neatly packaged, however you have to write that packaging yourself. Spring-Rich attempted to do this and that was a step in the right direction, but their latest post seem to indicate they are starting anew to use the OSGi-Spring integration.
The AppFramework was nice for newbies and for small->medium sized apps, but for enterprise apps or anything with lots of screens, or outfits with many apps, you need more. Swing developers have been shouting this message for years to Sun, but the interpretation has been BeansBinding and AppFramework and cooleffects. They have been off-target.
What’s needed is a client container inside JaveSE that makes building enterprise GUIs easy. It’s a simple idea – a replication of the JavaEE for the final front tier. Amy, this was posed to your team at JavaOne desktop discussions as far back as 2001. Can we expect some leadership in this area?
June 7th, 2008 at 8:47 am
I delivered this last year for traders to look at historical prices.
https://www.dev.java.net/files/forums/1753/2957/2092/NewBackGroundColor.PNG
After I delivered it we had a change in management. The new manager had us talk to other people in the division and find out how everyone else was getting things done.
We looked at many web based FLEX and AJAX systems. We also looked at a few C# applications.
EVERYONE told me afterward that my application was the quickest and most professional of all the other applications.
Steve Jobs had the courage and vision to stay with Mach and Objective C for the engine of OS X. I’m amazed that nobody at Sun’s executive level understands just how great Swing is and what can be achieved with the technology.
Swing is proven technology that I plan on using for a few more years to say the least. As soon as Apple can get their act together I plan on making a mint moving custom applications over to OSX and Java.
Cheers and kudos to the Swing team.
June 10th, 2008 at 10:08 am
As someone who has worked with Swing since 1.0.1, I can say that it is the best all around gui library for just about any task. Using it as a dual-app (one with both an applet and application start point), gives it an edge against any other solution on the marketplace. In fact, I can’t understand why anyone would EVER develop a web application again (in JSF, JSP, or html) once they understand how to develop Swing applications. Sun would be making a considerable error in judgement to ever consider shelving it. Thanks for doing your part to keep it alive Amy. :-)
October 26th, 2008 at 12:37 pm
=== 24 october 2008:
I saw java 1.6 Update 10 is finally out pulic.
Great news.
So, I also tried javaFx to see why people said so much bad things about it.
And after half a day I was really conviced.
Why :
- Syntax is almost java’s syntax … without complicated things in java language (I ain’t lost at all… I was happilly surprised)
- Code is beautifully packed. you can jump in somoene module and understand it easilly.
- (and of course) Yes we can do visual COOL things I found difficult to do in Swing.
Really I wish javaFx great success. For me as a Swing developper it is really cool.
I just don’t get why so many people say bad things about it. Perhaps they did not try it….
Thierry
November 1st, 2008 at 5:14 am
Now, many moons later, we have just learned that Sun shortly after that interview with Amy Fowler in May froze the funding for SwingX in SwingLabs.
What was that comment in May?
> Reports of Swing’s demise are greatly exaggerated.
Haha!