Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

Client-side Java's evolutionary leap

Looking back on a year of changes

By Jeff Friesen, JavaWorld.com, 01/29/09

  • Print
  • Feedback
.

Page 6 of 6

Sun engineers came away from the summit with a laundry list of JVM change requests, including the need to plan for tail call optimization and value types. Given the summit's success, there is a good chance Sun will host another one in 2009.

Swing, SwingX, and JavaFX

For many Swing/SwingX developers, 2008 proved to be an uncomfortable year. Developers in these camps disapproved of Sun's emphasis on JavaFX, viewing it as hurtful to further Swing development. They were also outraged over Sun's decision to stop funding the SwingX project.

Kirill Grouchnikov (creator of the popular Substance look and feel, and the Flamingo ribbon component) contributed to the controversy when he wrote the blog post "Sun setting down on the core Swing." I asked Grouchnikov to clarify a couple of points:

Q: Your blog post begins: "Core Swing is in the process of being retired as a legacy user interface technology inside Sun." Are you suggesting that Sun has no future plans for Swing? Has the situation changed since you posted this topic?

Kirill Grouchnikov: Contrary to the declarations of openness that Sun has made over the last couple of years, it has been extremely opaque and uncommunicative about its short- and long-term plans for client-side Java, besides the heavy marketing of JavaFX. The client market is an extremely competitive landscape, and Sun is lagging behind as far as rich applications go. Given this, I do not see any justification for withholding information from the very people that are still seeing potential in Java on the client in general, and Swing in particular. It has been my feeling over the last 18 months that Sun's heavy involvement with JavaFX has effectively stopped any unrelated work on Swing.
While we finally did see some long-awaited features, such as translucent and shaped windows, these clearly have been added because of JavaFX. I do not see Swing as being the top priority of the new and targeted development in the near future. Obviously, the policy of never removing functionality from the JDK means that Swing is still with us in JDK 7 and beyond. But my feeling still is that it will only receive cosmetic treatment, with higher priority given to the bugs and features that are deemed crucial to the success of JavaFX.
Since that posting, there have been indications of possible inclusion of new Swing modules in JDK 7, such as Application Framework, SwingX painters, a few chosen SwingX components, and (one of my favorites) JXLayer. At the present moment, allow me to remain skeptical and wait for these promises to be backed up by real actions. JavaFX is far from where Sun wants to see it and will continue demanding significant engineering resources throughout 2009 and well into 2010.

Q: Your post also says: "According to Jeanette Winzenburg's post on the SwingLabs Java.net forum, Sun has stopped funding of the SwingX project." How does a funding cut impact the continuation of SwingX development?

Kirill Grouchnikov: SwingLabs was born around 2004 and has created a lot of hope in the Java client community. It was promoted as the testing ground for developing new line-of-business Swing components (JDNC project) for subsequent inclusion in the official JDK distributions. It was led and staffed by Sun's engineers and has managed to gather a vibrant collection of community participants who wanted to move Swing forward. Additional initiatives were focused on better platform integration (JDIC), related layers (group layout, timing framework, and animated transitions) and emergent technologies (integration with Web services and mapping widgets).
Some of the initial promises came to fruition in JDK 6, which saw inclusion of a few reworked JDIC classes and select table APIs (mainly sorting). Unfortunately, 2006 witnessed a fallout in the community participation. Although I have not been an active participant in SwingLabs and SwingX (rebranded JDNC), I believe that many were disappointed with the lack of progress on including the SwingX components in the core JDK distribution. Some community members were also pushing for significant changes in how the Swing core painting pipeline works. This has resulted in a long series of discussions on painters, user-interface delegates, and related subjects. The eventual decision of the project's lead to not continue down the path of including the proposed painter infrastructure in the core JDK has proved to drive off yet more outside participants.
Since then, the development of SwingX has continued at a much slower pace, and the recent announcement of removing the funding effectively leaves all the work on SwingX in the hands of community volunteers. While their work is highly appreciated, lack of a 1.0 release even after four years of work is hardly encouraging commercial companies to develop using SwingX. There are quite a few great components in SwingX that support core look-and-feels, in addition to providing extension hooks for third-party ones, and I do hope to see some of those components in the core Swing library.

As the chief architect of Sun's client software, Danny Coward decides what makes it into the next JDK. I asked Grouchnikov what he thinks is the top item Coward should address in regard to Swing for JDK 7, then passed his comment on to Coward for a response.

Kirill Grouchnikov: Break binary compatibility. This thing has been hampering the progress of Swing for too long. If people don't want their applications to be broken, they can either use older JDKs or invest some time in migrating to the new APIs. Don't replace the toolkit (re JavaFX). Instead, evolve it in a controlled way that still allows you to experiment and make mistakes. When you make a mistake, admit it and learn from it. But don't be afraid to evolve the platform.
In my view, JavaFX is replacing Swing as the main user interface toolkit that Sun's client team is working on and recommending for writing new applications, as well as migrating existing ones. I would rather see Sun evolve Swing, even if it means breaking existing APIs, to bring it on par with the requirements of modern applications and RIAs, as well as address the existing shortcomings (binding, animations, and so on).
Danny Coward responds: Maintaining backwards compatibility has been the virtue and vice of the Java API set since 1996. On one hand we have this big issue with people still on older versions of the JDK because they are hesitant to migrate in case something breaks (the issue for us being that we spend engineering time maintaining a trail of old JDKs instead of working on new stuff). On the other hand people like Kirill are busy innovating, and the JDK is a great vehicle to get new and experimental ideas out even if some of them turn out to need changing. But I don't think it's one thing or the other: I think there are ways of supporting that experimentation on top of the APIs without experimenting with the current API set. This is the path that Java EE is on: the basic stuff is there, many developers now use one framework or another on top of the Java EE APIs, and the EE APIs are in this mode of enabling those frameworks better, extensible deployment descriptors and use of annotations being two examples. With the rise of JavaFX (which uses many of the Swing components in the desktop profile) and RIA frameworks like Griffon (Swing + Groovy) I think the scene is set for us to think about what those enablers are, the Swing App Framework being a good example.

Richard Bair is a longtime speaker and member of the Swing Team at Sun. He also leads the development of JavaFX's component toolkit API. I asked him about Swing/SwingX, including a comment he made in an interview with Kirill Grouchnikov:

Q: In your December 5 interview with Kirill, you said: "To those people who say we should make a Swing2 which is not backwards compatible, I would say, this is exactly what we're doing with JavaFX." Various sources have interpreted this comment to mean "JavaFX = Swing 2.0". Is this a fair assessment?

Richard Bair: Yes, that's exactly the message I was trying to convey. JavaFX will have a completely new Control library, which will be essentially Swing 2.0. We're taking all the good things from Swing (including property names and so forth where it makes sense), all the good things from SwingLabs, all the lessons learned, and applying them to a new toolkit.
I should add that JavaFX is much more than just the next Swing -- it also has Web services APIs and so forth. It is really the next client stack from Sun Microsystems built on the foundation of the Java platform.

Q: Many developers are frustrated by Sun's emphasis on JavaFX at the expense of Swing and SwingX. Was there an overlooked bright spot for Swing/SwingX in 2008?

Richard Bair: It's true that getting JavaFX released has been a lot of work and required a necessary refocus of developers within Sun to get it out the door. I think that as Swing developers become more familiar with JavaFX and as we begin releasing more enterprise application components into JavaFX, Swing developers will be very excited with what they see.
I think one fantastic development in the Swing world has been the growth of strong third-party contributors to the world of Swing. We've also seen several "Swing 2.0" projects start this year, which is great. It shows the strong interest that Swing developers have in seeing desktop Java succeed. JavaFX is really about amplifying that success. We're very strongly committed as a team and as a company to the success of the client Java platform.

Q: Although Swing is a mature technology that's widely used in enterprises, it has a large footprint, and it appears that much work would be needed to integrate SwingX components into Swing. Do you see Swing continuing to grow, or do you see a time approaching when future work on Swing will be halted?

Richard Bair: We are building a new toolkit for JavaFX which takes all the best from Swing and SwingLabs and the JavaFX Script language to create what I think is shaping up to be a really powerful library. Swing will continue to grow and be supported. The important thing to understand is that, as you said, Swing is a very mature technology, which is deployed and used by our customers with millions and millions of lines of code, and as such will continue to grow, but at a slower pace than a young toolkit would. Will we add some more components? Yes, we have plans to bring a few more components from SwingLabs into Swing.
We're also planning on finishing the work on JSR 296 (the Swing Application Framework) for Java 7. So clearly we're still investing in Swing technology.

Also noted: OpenJDK, Ganymede, desktop apps

Sun's JavaOne 2006 announcement that Java would be open sourced led to the formation of the OpenJDK project, which is creating an open source version of JDK 7. OpenJDK experienced some milestones in 2008. A completely open source JDK 6 was bundled with the Fedora 9 Linux distribution. Perhaps a more significant development was the announcement of the first code committed to OpenJDK by Roman Kennke, who is not a current or former Sun employee. More committed code from others not involved with Sun is likely to follow.

While Sun was busy working on NetBeans, the Eclipse Foundation was busy with its rival IDE. In June, the foundation released Eclipse Ganymede, which contained version 3.4 of the Eclipse platform and 23 projects. Another interesting development occurred at EclipseCon in March, where Microsoft's Sam Ramji announced the beginning of Microsoft's collaborative work with the Eclipse Foundation.

Other members of the Java community were busy releasing client-side Java products in 2008. For example, Michael Kölling introduced a BlueJ plugin for NetBeans 6.1 (in September) and BlueJ 2.5.0 (in October). I asked computer science professor and Java author Cay Horstmann to look back over 2008 and tell us which product(s) made the biggest impression on him:

Cay Horstmann: It is sad that I had to think quite a while about this question. BlueJ is a great product, but a BlueJ 2.5.0 release in October is hardly a validation of client-side Java. In fact, I could not think of a single exciting desktop Java product that came out in 2008. I am looking forward to the new version of Alice, which will be exciting, but that's in 2009.
I am certainly in the target audience for Java-based apps. I mostly run Linux, and sometimes Mac OS X and Windows. Cross-platform is very important to me. I run Eclipse or NetBeans every day. Apart from that, the pickings on my computers are pretty slim: Alice, BlueJ, Dr. Java, ExecuteQuery, GanttProject, Greenfoot, jUploadr, SQuirreL, Violet.
Why is that? The standard argument is that Swing apps are slow, look ugly, or hard to code. Slow? I don't know -- Eclipse and NetBeans are huge programs but they run fine for me, certainly no slower than Visual Studio. Ugly? As a Linux user, I have to laugh. Most of the apps that I use everyday (OpenOffice, Amaya, Thunderbird) are even uglier. Hard to code? It is way harder to program in GTK+, wxWidgets, or XUL than in Swing.
I do see plenty of interesting projects in research and education, and Java is used for almost all of them because it is cross-platform and easy to program. But there is a fly in that ointment. Java is way behind in support for modern hardware (pen or touch input) and media types (audio/video). That's where a lot of action is, and Java will lose its natural advantage quickly if it doesn't catch up.
Of course, if you asked me to name an exciting C# or Flex app that blew me away in 2008, I'd have the same answer: None. So maybe this is all just a sign of maturity in desktop apps.

On the horizon for 2009

As we look ahead into 2009, we can be certain of some upcoming developments in client-side Java. For starters, JDK 7 will be previewed at JavaOne. Also, we'll witness the arrival of JavaFX Mobile SDK and other JavaFX releases. Undoubtedly, we'll finally get to play with JWebPane. And we can count on a few other developments.

JavaOne 2009 and the JDK 7 preview

In mid-December, Danny Coward announced that JDK 7 will preview at the JavaOne 2009 conference and shared the strongest indications to date on some of the items that will make it into JDK 7:

  • Project Jigsaw for modularizing the JDK
  • New low-pause garbage collector (Garbage First)
  • Better performance
  • Language changes
  • NIO2 (New I/O, the next generation)
  • Swing Application Framework
  • Annotations on Java types
  • XRender graphics pipeline
  • Stream Control Transport Protocol (SCTP) support
  • Unicode 5 support

Coward refers us to Joseph D. Darcy's blog to learn more about upcoming language changes. In his post Coming Soon: A JSR for small language changes in JDK 7, Darcy mentions that he is heading up Sun's efforts to develop a set of small language changes in JDK 7 and will submit a JSR for them in the first half of 2009. I had some questions about that.

Q: Can you tell us about any small language changes that will definitely appear in JDK 7?

Joseph Darcy: Nothing is certain yet, but strings in switch and more concise declarations to initialize generic variables are very likely changes.

Q: Are there are any plans to further enhance generics in JDK 7? For example, can you tell us if Bug 5098163: Add reification of generic type parameters to the Java programming language will be addressed?

Joseph Darcy: No, adding reified generics will not be done for JDK 7; some of the rationale is discussed in my  measuring language change size blog post. Reification would not be a small change; nontrivial JVM enhancements would be needed to maintain performance, and there are various compatibility issues that would have to be worked through.

Q: Does Sun plan to address this bug in JDK 8?

Joseph Darcy: I think we need to get a bit further through JDK 7 before much planning for JDK 8. Adding reification would intrinsically have a somewhat high effort compared to the potential reward, since only programs that wanted to use certain kinds of reflective operations would benefit.

Project Coin

Subsequent to our discussion, Joseph Darcy announced Project Coin, an OpenJDK project for hosting the small language changes to be introduced in JDK 7. Darcy mentions that both this project and a mailing list for proposing language changes will debut in February.

While thinking up a potential small language change, keep in mind that Darcy is already considering adding strings in switch, more concise calls to constructors with type parameters, exception enhancements (multi-catch and final rethrow), the ability to call foreign language methods with exotic names, and (possibly) bracket notation to access collections.

We can add Java SE 6u10 features (Nimbus, translucent/shaped windows, Java Kernel, and so on) to the previous JDK 7 feature list. And, in light of the news from the JVM Language Summit that Java 7 will include invokedynamic, we can safely add a new JVM with this instruction (and possibly other features for supporting dynamically typed languages).

It seems less certain that Java Media Components and Project Scene Graph will officially debut in JDK 7. I asked Danny Coward to set the record straight:

Q: Will Project Scene Graph and Java Media Components be integrated into core Java starting with JDK 7? Their presence would allow Swing developers to take advantage of keyframe animation, visual effects, and media without having to write code in JavaFX Script. It seems that many Swing developers would prefer to avoid JavaFX.

Danny Coward: We don't know yet if exposing the scene graph and media functionality will make it into the preview for JavaOne 2009; I know there are many developers who would like us to do that. Our top priority this past year was to make the first launch of JavaFX in order to try to attract a new kind of developer to the Java platform and so some of the features are not exposed in the Java programming model (although some others are). There are various backdoor ways to get at it (see Josh Marinacci's blog) for now for the real enthusiasts.
I know that there are some Swing developers who were skeptical about JavaFX ahead of the 1.0 launch, although it's interesting that many of them want to use some of the main concepts of JavaFX like the media and the scene graph. I hope they will try it out now that the SDK is out there before they make a judgment. Remember, it was a Swing developer (Chris Oliver) who created JavaFX Script in order to make creating great looking GUIs much easier, and possible to do for a wider crowd of developers, not just the seasoned Swing experts.

After reading Coward's answer, I started to think that if an API (or some other feature) doesn't appear in the JDK 7 preview at JavaOne, then just maybe the API might get slipped into JDK 7 between then and its final release in 2010:

Q: Can further changes be introduced into JDK 7 after its JavaOne preview and before its 2010 release, or is its feature set considered final at the preview?

Danny Coward: We will likely decide this prior to the preview release of JDK 7 at JavaOne, since we hope to be mostly feature complete for that release so we can get any final issues sorted out before going into the last phase before final release in January. We want to get some feedback on the functionality in JavaFX before we make the call.

In case you missed it, Danny Coward stated that the final release of JDK 7 will arrive in January 2010!

Many developers will probably be excited when the JDK 7 preview hits -- especially fans of NIO2, the Swing Application Framework, or dynamically typed languages. Others will only be mildly interested. For example, I recently asked Cay Horstmann to tell us about the language features and APIs whose additions would get him excited about JDK 7:

Cay Horstmann: I want to see a solution for properties. It isn't sexy, but it is the cause for a large amount of boilerplate, and boilerplate is always bad. Type inference for variable declarations and "multicatch" also reduce boilerplate and would be very welcome. And I'd like to see generics fixed. I really dislike worrying about pitfalls with erasure and boxing, but I don't know enough about the technical details to understand whether a fix is feasible.
A whole slew of, I think, rather misguided little syntax hacks are currently being floated in various polls. Those hacks could be easily expressed in the language if it had closures and operator overloading. I much prefer a small set of strong features over a large set of special rules. As for APIs, I certainly look forward to the Swing App framework and beans binding.
Video support is a must. I also hope that whatever is behind JavaFX is being made available to Java programmers. In the "it ain't gonna happen" department, I fervently wish for an app installer, pen support, additional Swing components, and an editor pane that actually works.

On closures, one of the most controversial subjects of 2008, Horstmann had this to say:

Cay Horstmann: I like closures a lot, and I wish Java had them now. But I don't really see a way forward. I favor the BGGA proposal, but with Neal Gafter's move to Microsoft, it has lost a lot of momentum. CICE is better than nothing, but that would signal that Java is essentially frozen and needs to be replaced, not improved, in the fairly near future.

JavaFX throughout 2009

This year promises to be an exciting one for JavaFX. For example, Simon Morris posted JavaFX in Style (about skinning UI controls using CSS-like style sheets) on the last day of 2008, and Amy Fowler posted  Layout Primer for JavaFX1.0 a few days later. I'm certain that we'll learn even more about JavaFX as the year unfolds.

Although the JavaFX 1.0 release already contains a beta version of the FX Mobile runtime, which lets you run rich JavaFX applications on MSA-compliant mobile phones (or the SDK's mobile emulator), developers will wait until the February release of JavaFX Mobile to get our hands on the JavaFX Mobile SDK.

Other significant developments for JavaFX in 2009 are likely. A visual designer tool for JavaFX is expected to be released around midyear. We can look forward to JavaFX 2.0 (at least in preview form), which may or may not include the TV edition of JavaFX. Also, we can expect more JavaFX SDK updates following on the December 2008 JavaFX 1.0 SDK Update 1 release.

Other developments from Sun and elsewhere

In addition to the JDK 7 preview at JavaOne, more JavaFX product releases, and a chance to play with JWebPane, we can expect new versions of NetBeans and LWUIT throughout 2009. And we can expect new Java SE 6 updates. Java SE 6u12 should arrive soon; along with expected bug fixes, it will add:

  • Windows Server 2008 support
  • 64-bit Java plugin and Java Web Start support on the AMD64 architecture for Windows and Linux only
  • Limited mixing of heavyweight and lightweight components

I asked Richard Bair if he could give us a sneak peak at any unannounced client-side Java projects that Sun is planning for release in 2009. Although his reply doesn't reveal anything that hasn't been mentioned elsewhere, it nicely summarizes some of the features that will probably debut in JavaFX 2.0:

Richard Bair: I can't go into detail on things that haven't been announced, but I can say that we're working on a new user interface control toolkit, we're boosting performance of the graphics stack in JavaFX in a big big way, we're working on more and better Web services (RSS / ATOM / REST) support in JavaFX, we're working on an interaction designer tool, we're fixing more of the deployment and startup issues, and a lot more. I think it's going to be a really good year for client Java in 2009.

I'm especially looking forward to Pro JavaFX Platform: Script, Desktop and Mobile RIA with Java Technology by Jim Weaver, Weiqi Gao, and Stephen Chin. I asked Chin and Weaver about the book, which will probably be released in the first half of 2009:

Q: Can you tell us a bit about the Pro JavaFX book that you've been working on with Weiqi and Stephen?

Jim Weaver: [The book] will be a comprehensive guide to JavaFX, written in tutorial style. It is also being designed to serve as a reference, with lots of tables, etc. I'm very fortunate to have Weiqi and Stephen writing this with me, as they are both brilliant in the areas of Java and JavaFX. Dean Iverson, whom I mentioned earlier, is the technical reviewer.

Q: Stephen, can you tell us a little bit about your contribution to this book?

Stephen Chin: I am helping to build out a lot of the content on advanced layouts, enterprise integration, and the JavaFX mobile stack. It is a lot of work, but it is great to be doing this at a time when it is very much in need by the Java community.

As JavaFX becomes more popular, many developers will probably want to create JavaFX versions of their Swing products; some of these JavaFX versions should debut in 2009. For example, I think we'll see a JavaFX version of Mikael Grev's MiGLayout later this year. I asked Kirill Grouchnikov if he plans to migrate his popular Substance look and feel to JavaFX:

Kirill Grouchnikov: While I do not have any plans to stop supporting Swing applications in Substance, I have started to work on extracting the color and skin definitions into separate non-code files. On one hand, this is targeting the designer-friendly tooling to create Substance color schemes and skins. On the other hand, it might open a way to reuse Substance visuals in other user interface toolkits. JavaFX is one such option in that it supports CSS-like definitions of control visuals.
At the present moment, there is a severe lack of official documentation on the CSS skinning layer in JavaFX 1.0, but some of the community members have been actively pursuing this topic (for example, see  Simon Morris's skinning example). I hope that 2009 will see a tool that automatically converts Substance skin definitions into the matching JavaFX skin CSS files.

Finally, the Eclipse Foundation has distributed a simultaneous release of the Eclipse Platform and a variety of projects in late June of each year since 2006. The upcoming Galileo distribution is expected to arrive on schedule: June 26.

Summing up

Among 2008's client-side Java developments, I'm most impressed by three that hold much promise for the future of client-side Java:

  • Java SE 6u10: The arrival of Java SE 6u10 marks a starting point in improving the consumer's experience with Java. For the first time, users can start running a Java program without noticing a significant delay while the entire JRE downloads. This experience improved with Java SE 6u11 and should continue to improve with the successive updates and future JRE releases impacted by Project Jigsaw.
  • JavaFX: For the first time, it's possible to get user interfaces (and rich ones, at that) onto all of the "screens of our lives." As long as we target the common profile, a user interface looks/works the same across desktops, mobile phones, (eventually) television set-top boxes, (I expect) Blu-ray disc players, and so on. In contrast, Swing only lets us create user interfaces for the desktop. If we want to create a user interface for a mobile phone, we need to turn to the LWUIT.
  • Da Vinci Machine Project: Because current JVMs provide statically typed instruction sets, it isn't easy to support dynamically typed languages. Depending on the language, varying amounts of overhead are required, and this can impact a program's runtime efficiency. By making future JVMs more dynamic-friendly, I suspect that we'll eventually see more client-side development take place in dynamic languages than in the Java language. And we probably won't need to wait as long for new language features to arrive!

It's an open question how client-side Java's evolution will be affected by these challenging economic times. Can Sun afford to keep innovating Java when it's losing money on server sales and support contracts? Perhaps economics will ultimately force Sun to relinquish further client-side innovations, and Java, in general, to the open-source community (beyond OpenJDK). Regardless, it's certainly clear from the voices you heard in this article that the urge to innovate on the Java client is stronger than ever.

About the author

Jeff Friesen is a freelance software developer and educator who specializes in Java technology. Check out his javajeff.mb.ca website to discover all of his published Java articles and more. His recently published book Beginning Java SE 6 Platform: From Novice to Professional (Apress, October 2007) explores most of the new features introduced in Java SE 6.

Read more about Core Java in JavaWorld's Core Java section.

  • Print
  • Feedback

Resources

Also from JavaWorld