Client-side Java's evolutionary leap

Looking back on a year of changes

1 2 3 4 Page 2
Page 2 of 4
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.


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 ""?) 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 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).
1 2 3 4 Page 2
Page 2 of 4