Client-side Java’s evolutionary leap

Client-side Java was a source of both growing excitement and some distress in 2008, and looks to continue on that trajectory in ’09. Desktop developers are basking in a shower of new releases and innovation, while also facing the possible demise of Swing, unhappy trade-offs on the Java language front, and the question of whether Sun — or anyone — can continue to innovate in a worldwide recession. In this round-table discussion, Jeff Friesen invites leading lights in the Java community to discuss what is most compelling to them about the current moment in client-side Java development. Read on for reflections, predictions, a modicum of polemics, and some interesting scoops about what we can expect (and when) from client-side Java in 2009.

According to a poll on Java.net, two of the biggest news stories for Java developers in 2008 were the respective releases of Java SE 6u10 and JavaFX 1.0. These were not the only significant developments for client-side Java in the past year, however, and for some what may stand out even more strongly is the still brewing controversy surrounding JavaFX as the new Swing. It also seems clear that more excitement, on the JavaFX front and from other client-side technologies, is on the way in 2009.

All of this is, of course, a huge shift from the many years when client-side Java (under the auspices of Sun) seemed to nearly stand still. In this article I attempt to consolidate and make sense of the major developments for client-side and desktop Java in the year behind us. I then look forward, to scope out what’s on the horizon in 2009. Discussion is based on actual or pending product releases, official announcements, my personal observations, and the welcome commentary of influential members of the Java community. Sincere thanks to the following for their contribution to this article: Richard Bair, Tim Boudreau, Stephen Chin, Danny Coward, Joseph Darcy, Mikael Grev, Kirill Grouchnikov, Cay Horstmann, and Jim Weaver.

Reflections on 2008

Sun captured much of the spotlight shining on client-side Java in 2008. It released Java SE 6u10 and 6u11, JavaFX Preview SDK and JavaFX SDK 1.0, the LightWeight User Interface Toolkit (LWUIT), and NetBeans 6.1 and 6.5. Sun also hosted the first JVM Language Summit and, of course, the annual JavaOne conference.

Even with Sun shining so brightly, others in the Java community also made headlines in the client space. Controversy erupted over Sun’s emphasis on developing JavaFX largely at the expense of continued Swing development. The OpenJDK project committed its first contribution from a non-Sun/non-ex-Sun employee. The JFXtras and WidgetFX projects debuted. Even Microsoft made some Java news.

JavaOne 2008: JWebPane, MiGLayout, ‘Effective Java’ reloaded

Other than announcements of the forthcoming JavaFX SDK and a cross-platform video codec from On2 Technologies, JavaOne 2008 was disappointingly light on client-side Java news. For those seeking excitement in this space, technical sessions were a better bet.

One noteworthy session introduced JWebPane, a new HTML component for Java. JWebPane provides a much-needed replacement for Swing’s JEditorPane component, which renders only HTML 3.2. JWebPane is based on, and interacts with, the open source WebKit Web browser engine, which supports HTML 4, Cascading Style Sheets (CSS), JavaScript, and the Document Object Model (DOM). It takes care of Java tasks such as calculating component bounds, rendering, networking, and dispatching events, and its main JWebPane class subclasses javax.swing.JComponent. JWebPane project tech lead Alexey Ushakov announced in December that JWebPane’s code should be available in a few months, preceded by an API overview. Because it’s important to thoroughly vet a new API (to implement missing features or remove clutter) before integrating it into a JDK, and because the code is still under development, it seems unlikely that this highly anticipated component will make it into JDK 7.

Another session focused on Mikael Grev’s popular MiGLayout layout manager. I touched base with Grev about plans for MiGLayout:

Q: Could you briefly describe this layout manager and explain why it’s so useful?

Mikael Grev: MiGLayout positions components on screen using a powerful, but intuitive, domain-specific language (DSL). The popularity of MiGLayout, I believe, is that it is 100 percent optimized for the user. It has lots of built-in logic and platform rules so that the user only needs to give hints how the components are related, and MiGLayout does the rest. The Swing layout managers in the JDK use the opposite approach; they are architecturally very simple, and it is up to the user to make the decisions about gaps, positioning, and such. MiGLayout encapsulates all the functionality of almost all Swing layout managers. It also has all those nifty little extras such as resolution independence, visual debugging mode, and automatic gap and button order per platform handling.

Q: I understand that you are trying to get MiGLayout included as part of the JDK 7 core. How likely is this to happen?

Mikael Grev: I have no idea how likely it is, unfortunately. The RFE [request for enhancement] — which is the officially most wanted one for Swing, by the way — hasn’t after one and a half years gotten an official evaluation. I think the reasons are more corporate policy than technical; they might be reluctant to overtake the official responsibility for a relatively complex software since they didn’t write it in-house. But then again, that is what open source is all about. Some have voiced a concern that inclusion in the JDK would slow the development process of MiGLayout in the future. Since we are at zero known bugs and zero things to do, I don’t understand how that would apply.

Q: Do you have plans for a JavaFX version of MiGLayout?

Mikael Grev: MiGLayout was made from the start to be very easy to port, and it exists officially for Swing and SWT today. It only touches the GUI framework classes through three proxy interfaces, and these are the only ones to implement to port it to a new GUI framework. So there will be a JavaFX version because it should be easy to do, and there are developers wanting it, especially because there are no real layout managers there now as I understand it. Amy Fowler (from the JavaFX team), Dean Iverson, and I are currently outlining the details on how to do this the best way.

A final highlight of JavaOne 2008 (for this developer) was the Effective Java Reloaded session, in which former Sun employee Joshua Bloch launched Effective Java, Second Edition. This successor to the popular first edition, released in 2001, offers even more insights into writing quality Java client (and server) code.

Java SE 6u10 and 6u11

It’s a well-known fact that the Java client platform has for years suffered limitations that have made it a less desirable alternative to competitors such as Flash and Silverlight. For example, the entire Java Runtime Environment (JRE) must be present before an applet or Java Web Start application starts running. JREs keep getting bigger (JRE 6 exceeds 14 MB), so download times keep lengthening. To address this limitation and others, Sun engineers conceived of Java SE 6u10 (called the Consumer JRE when the early-access version came out in 2007, then Java SE 6uN). A beta version debuted in April 2008, and the final release was in October.

The following technologies in Java SE 6u10 help overcome JRE limitations:

• Java Deployment Toolkit: Simplifies the task of deploying applets and applications to a variety of clients. It consists of a JavaScript file and a browser plugin that make it possible to install a JRE automatically.
• Java Kernel: Lets first-time Java users run applets and applications faster by downloading only that part of the JRE needed to run the applet/application immediately. Then it downloads the rest of the JRE in the background.
• Java Quick Starter: Prefetches portions of the JRE into a memory cache, greatly reducing the average Java Platform cold startup time (the time to launch a Java applet or application for the first time following a computer reboot).
• New Java Plugin: Improves reliability by running applets in operating-system processes separate from the browser. If an applet fails, the browser is unaffected. Other improvements include each applet being able to increase its heap size, and improved Java-JavaScript communication.

Java SE 6u10 also includes bug fixes, Nimbus (which modernizes Java’s cross-platform look and feel), a new graphics pipeline that uses Direct3D to accelerate Java2D graphics primitives on Windows, and support for translucent/shaped windows.

In December, Sun released Java SE 6u11. It focuses on security and bug fixes. A new download engine works with 6u10’s patch-in-place strategy (future JRE updates are applied in the existing JRE directory so that only changed files need to be downloaded) to reduce the size of future updates. To avoid interfering with a user’s Internet usage, this engine monitors that usage and throttles back its own bandwidth.

JavaFX Preview SDK and SDK 1.0

JavaFX was a source of both excitement and dismay in 2008, with three especially striking highlights. First, then-Sun employees Hans Muller and Chet Haase gave developers a peek into the Java-based scene graph and animation frameworks that would support JavaFX via Muller’s Introducing the SceneGraph Project and Haase’s  Been There, Scene That, Part 1 and Part 2 blog posts.

Second was the launch of the JavaFX Preview SDK on July 31. It provided a JavaFX plugin for NetBeans 6.1, which let you easily compile scripts from the IDE. The Preview SDK also provided Project Nile, whose Adobe Illustrator and Photoshop plugins made it easy for content designers to export their designs to JavaFX developers.

Third was the release of the official first version — JavaFX SDK 1.0 — on December 4. It included an updated JavaFX plugin for NetBeans 6.5, with refinements to JavaFX Script and new/improved APIs. We were also treated to the JavaFX Production Suite, an updated successor to Project Nile.

Many developers are now using JavaFX SDK 1.0 to create exciting applications. I spoke with JavaFX pioneer Jim Weaver (who teaches JavaFX via his book, JavaFX Script: Dynamic Java Scripting for Rich Internet/Client-side Applications and via his JavaFX blog) about the SDK:

Q: What are your favorite JavaFX features?

Jim Weaver: One is the graphical node-centric approach, where any user interface element (button, video, image, layout, and so on) is a node in a 2D scenegraph and can be graphically transformed/animated/etc. This ability is conducive to creating the iPhone-esque/Web 2.0++ rich Internet applications that users are coming to expect. Another favorite feature is its ability to instantiate and use the millions of Java classes that already exist. JavaFX is rich-client Java, which is a huge advantage.

Q: Are there any language features or APIs that you would like to see introduced into a future version of JavaFX Script?

Jim Weaver: Because JavaFX is currently a 1.0 release, of course there are additional features and fleshing out of some current features that I’d like to see! For example, a couple of the packages in the 1.0 release are a little short of classes:

• The javafx.scene.layout package needs more layout classes in future releases. JavaFX has a graphical node-centric user interface (think more Java 2D and less Swing), so the future layout strategies and classes need to be designed accordingly.
• The javafx.scene.control package contains classes that provide the ability to have CSS-styled and skinnable user interface controls, but there is only one user interface control (TextBox) in that package. For other user interface controls, JavaFX uses Swing under the covers. Dean Iverson wrote an excellent article about these classes in the JavaFXpert blog, in which he builds upon a very helpful article and example by Simon Morris.

There are other features, such as a unit-testing mechanism, an easier-to-use asynchronous threading model, charting/graphing classes, and so on that are being addressed by the JavaFX teams at Sun, and by the JavaFX community. For example, an open source project named JFXtras, led by Stephen Chin, was created to address the gaps in the 1.0 release of JavaFX.

Up and coming: JFXtras

Intrigued by Weaver’s comments, and by what I’d heard after the release of JavaFX 1.0, I checked in with Chin about this JavaFX release and his JFXtras project.

Q: What is your favorite part of JavaFX? What improvements to JavaFX Script, JavaFX APIs, or anything else specific to this technology would you like to see in future JavaFX SDK releases?

Stephen Chin: I would have to say that JavaFX has turned me into a bind-a-holic. I use bind for everything from user interface/model synchronization to GUI layout to inversion of control (IoC) patterns. I don’t think I can go back to the old way of doing things with event listeners and getter/setter methods anymore.

In terms of improvements, I tend to look at things from a different perspective. Rather than thinking “why can’t JavaFX do this for me?”, I instead find myself struggling with “there has to be a way I can build XYZ.” That said, here is my wish list for Sun:

• JavaFX API source code: Reading through all the user interface bits in the JavaFX Preview Release was not only enlightening (they have some really high-caliber engineers), but also a necessary survival trait to live on the bleeding edge. Since then, I have been entertaining myself with decompiled JavaFX code, but deciphering compiler internals is getting old.
• Embedding JavaFX in Java: For a lot of real-world applications, rewriting everything in JavaFX upfront is just not an option. It would be great to be able to pop JavaFX scenes in legacy Java applications to ease migration and handle some advanced requirements.
• Web 2.0 integration: There are a wealth of services and technologies that would greatly accelerate the adoption of JavaFX. Some examples of this are integration with mapping services, such as Google Maps, and embedding of Flex/Flash applications. The more all-inclusive JavaFX becomes with its integration strategy, the wider the developer community Sun will be able to reach.

Q: Could you describe your JFXtras project for the benefit of those not familiar with it?

Stephen Chin: JFXtras is a project for the JavaFX community written by the JavaFX community. Sun has been doing an excellent job of stewarding the JavaFX technology stack by maintaining a robust set of APIs that they can maintain and support going forward. On the JFXtras project, we are focused on filling in all the little holes and gaps that are needed to build real-world applications in JavaFX today.

If you think of JavaFX Script as the foundation of Java RIA applications, JFXtras provides the tool chest of components and add-ons that developers need to build full-featured products. All of the components in JFXtras are fully documented and tested, and released under a commercial friendly open source license that allows them to be used and extended by the community.

Q: What new features are planned for JFXtras?

Stephen Chin: Since the JavaFX 1.0 release is barely a month old, everything we are doing is new and exciting. The first 0.1 release of JFXtras featured a flexible Grid Layout, Java Dialog support, an Asynchronous Worker class, a declarative unit-testing framework, and lots of small enhancements. Basically, anytime someone on the mailing lists asked a question to the JavaFX team about “how can I do this?” or “is there support for XYZ?”, I was busy hacking together a code solution in the background that could be leveraged by the entire JavaFX community.

While the 0.2 release content is not finalized, we are planning to make a big splash with a new vector shape library built on top of jSilhouette. Andres Almiray has joined the JFXtras teams as a full contributor and is in the process of building the JavaFX layer, which will provide everything from traditional Crosses and Stars to Astroid and ReuleauxTriangle shapes.

Some other exciting things we have in the pipeline include:

• Graphing and charting support
• JavaFX menus
• Custom components galore!

And, of course, we are planning to branch a mobile distribution so that the JFXtras components that are not dependent on Java desktop technologies can be deployed on the upcoming JavaFX mobile platform.

Note: According to a recent blog post by Jim Weaver, JFXtras 0.2 is now available for download.

LWUIT

Mobile device developers celebrated the arrival of the LWUIT. This successor to Limited Capability Device User Interface (LCDUI ) provides a more sophisticated API that lets you take advantage of Swing-like capabilities (without having to put up with Swing’s complexity) for creating the UIs for mobile applications. More specifically, LWUIT targets Java MIDP and Swing developers who want to enhance the UIs of new or existing Java ME applications on MIDP 2.0 devices. It offers a wide range of widgets, theming, animated transitions, and more.

NetBeans 6.1 and 6.5

Many users of Sun’s NetBeans IDE regard each new release as a significant event. The arrival of NetBeans 6.1 in April, which included many new and noteworthy features, was widely anticipated. Sun later used version 6.1 to host the Preview SDK’s JavaFX plugin. Around mid-November, Sun released NetBeans 6.5. Among its new and noteworthy features is the first-ever support for Groovy. You can now easily and more rapidly create client-side applications that are 100% pure Groovy or a mix of Groovy and Java. Sun has also integrated JavaFX 1.0 into NetBeans 6.5.

I checked in with Sun’s NetBeans evangelist Tim Boudreau on what he considers to be the most important new features in NetBeans 6.5, and what’s ahead for NetBeans.

Q: What would you say are the most important new features in NetBeans 6.5?

Tim Boudreau: I can think of my favorite new features; most of them sound dull since they’re things that let me type less to get what I want. Probably my favorite sounds really silly: being able to type CTRL+SHIFT+; to append a semicolon to the current line, to insert a new, properly indented line below the line I’m on, and to move the caret there (all that in one keystroke).

Boudreau also mentioned NetBeans 6.5’s beefed-up support for non-Java (PHP, HTML, JavaScript, Ruby, and Python) development.

Q: Can you give us a timeline of new NetBeans releases for 2009, along with a glimpse into new features they’ll include?

Tim Boudreau: The best way to get a glimpse is to download a development build (hint, hint)! Two features that are coming along nicely and will be of interest to Java developers are:

• Automatic Projects: This plugin will recognize any directory with a build script as a project, analyze what the build script does (it’s even usable in wild scenarios like generating some sources and compiling them as a build phase), and set up your classpath, code completion, etc. with no configuration necessary. You can get this from the update center and try it out right now.
• Compile-on-save: A lot of developers have asked for this, but actually creating this feature was complicated by one of the benefits of NetBeans: it uses Apache Ant under the hood for its project infrastructure. With NetBeans 7, compile-on-save will be included, and it does save time on recompilation.

Larger-scale changes in NetBeans 7.0 (or should we just say “netbeans.next”?) are things like support for JavaFX and Python: we are continuing to add to the list of languages NetBeans works really well with and reach new audiences. A good way to keep up-to-date on new things as they’re added is to use NetBeans Twitter.

JVM Language Summit

A review of 2008’s JVM-oriented developments reveals Java becoming more of a platform-centric technology and less of a language-centric one. While many worry that the evolution of the Java language has slowed (JDK 7 will bring a few small language changes, but apparently nothing significant), the JVM itself is undergoing a renaissance of innovation.

In January 2008, Sun initiated the Da Vinci Machine project, also known as the Multi Language Virtual Machine. This project aims to introduce a JVM that supports dynamically typed languages efficiently. This support includes invokedynamic, a JVM instruction that allows method invocation to rely on dynamic type checking.

Because Da Vinci needs input from the dynamic language community to help guide its development, JVM engineers from Sun hosted the three-day JVM Language Summit at Sun’s Santa Clara campus in September. On the first day, Principal Engineer Mark Reinhold stated that invokedynamic will be part of the JVM, starting with JDK 7.

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.

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.