JW soapbox: Let's stop the FUD about JavaFX and deprecate the Java Plug-in

Why HTML5 is no JavaFX killer, and why it's time to let the Java Plug-in go

While HTML5 is a solid challenger to rich-client frameworks like JavaFX, Java developers have reason to question current thinking that says native apps are out of the game. And for those claiming that Java will soon be eliminated from the browser, I say the sooner the better.

Recent articles published by InfoWorld have rehashed a theme familiar to most Java developers by now: that of the aged and dying client-side Java platform, ready to be put to rest. Altogether, the three articles -- Paul Krill's "Oracle's latest JavaFX move: Too little, too late," Neil McAllister's "Last call for client-side Java," and Woody Leonhard's "It's time to run Java out of town" predict (and in the last case celebrate) a dim future for client-side Java.

But how realistic are these authors' claims?

What is client-side Java?

In web programming, the word client means any software that interacts with users through a user interface. Client-side Java refers to a Java platform environment that supports the execution of clients. Both Java ME and Java SE can be used for client-side development on the Java platform. Java ME's Connected Limited Device Configuration (CLDC) can be used to run clients on small, minimally powered devices, while the Connected Device Configuration (CDC) is used to run clients on larger, more powerful devices. On Java SE, we have the Abstract Window Toolkit UI architecture and API, as well as higher level APIs such as Swing and Java 2D, which are used to develop desktop clients. JavaFX has emerged as a drop-in replacement for AWT, Swing, and Java 2D. But JavaFX isn't only good for desktop apps.

Is HTML5 a JavaFX killer?

Could HTML5 really bury JavaFX? Contrasting the two technologies is one way to find out. To start, HTML5 is completely open and not owned by a major corporation, whereas JavaFX is owned by Oracle. Part of JavaFX has already been open sourced, however, and work is ongoing to open source even more of it. Open sourcing JavaFX is the most efficient way to build a competitive ecosystem and community for JavaFX. It makes sense for Oracle's bottom line.

One of HTML5's strongest selling points is deployment: the technology is broadly available through HTML5-compliant browsers that run on desktops, smart phones, tablets, and other devices. While JavaFX isn't yet available for smart phones or tablets, it does (as of JavaFX 2.1) run on Windows, Mac OS X, and Linux desktops. Furthermore, Oracle demonstrated at JavaOne 2011 that it could run JavaFX 2.0 on tablets and other devices -- namely an Apple iPad 2.0, a Samsung Galaxy Tab 10.1 running Android 3.1, and an Acer Windows 7 tablet. (For the iPad, a special Java ME virtual machine CDC was packaged with the iOS app.)

HTML5 does have a serious edge over JavaFX when it comes to tooling. Tool support for JavaFX so far is limited to NetBeans. Oracle recently announced the beta version availability of its Scene Builder tool for rapidly developing JavaFX applications, but that is hardly enough.

Another area where HTML5 is winning is the app store. Google's HTML5 app store, launched in 2010, offers free and paid web apps for Chrome. Mozilla is reportedly testing its own HTML5 app store, and so has AT&T. JavaFX currently has no such app store.

HTML5's advantage for writing and widely deploying rich web applications is impressive, but it could prove to be passing. Those who say otherwise may not fully appreciate the difference between web apps and native apps.

Web app versus native app

What should really differentiate HTML5 and JavaFX from a developer's perspective is the type of app that you want to build: a web app or a native app. HTML5 (along with CSS3 and JavaScript) is used to create browser-based web apps, which can only leverage features provided by the browser. Developers are limited to the features supported by the browser, with additional features accessible only through plugin extensions. HTML5 is also somewhat inconsistently implemented across browsers, which can force developers to write more complex code to adapt to different scenarios. All of this is not to say that developers shouldn't use HTML5 for some kinds of application scenarios; it's simply a reality check on the idea of HTML5 as a panacea.

JavaFX-based native apps can run in browsers but they're not limited by them. More important, JavaFX native apps can use any Java runtime-accessible feature, meaning that they have the entire Java API stack to work with. If a feature isn't supported by a given deployment environment (such as a Windows desktop) developers can use the Java Native Interface to create that support. While some native apps are locked into one or a few platforms -- for instance, an Objective-C based app won't run on an Android device -- JavaFX-based native apps aren't restricted to a single platform. A JavaFX app can run anywhere that there is a Java runtime (JRE).

Java Native Access

Using the Java Native Interface to port a Java application to an unsupportive environment raises the spectre of a portability violation. Learn how the Java Native Access project makes it possible to extend Java with JNI capabilities in a portable way.

Additional JavaFX advantages

Some have questioned Oracle's decision to build up JavaFX, rather than laying it to rest. But JavaFX has some serious advantages over HTML5, which its detractors should not ignore.

For one thing, JavaFX has Oracle. The company has been keeping its promises about the client-side platform, and it appears to believe it can monetize that commitment. In 2011, Oracle announced that it would get rid of JavaFX Script, re-architect JavaFX in Java, and further develop JavaFX's API suite. It has also recently released a beta version of the JavaFX Scene Builder tool for testing. These updates have been well received by Java developers interested in client-side development. The recent hiring of JavaFX rock stars Jim Weaver and Stephen Chin to evangelize the technology also demonstrates that Oracle believes it can get more developers interested in writing JavaFX-based UIs.

Perhaps more important to JavaFX's potential success is Java ME, which according to Oracle runs on at least three billion smart devices. At JavaOne 2011, Oracle announced its intention to make JavaFX the graphics framework of choice for mid-range and high-end Java ME-accessible embedded platforms. Combining JavaFX and JavaME could expand JavaFX's reach both rapidly and massively.

Don't just block Java Plug-ins -- deprecate them

Mozilla recently announced that it will block outdated Java Plug-ins from working in its Windows-based Firefox browsers. This is in order to prevent a security vulnerability within those plugins from being exploited. The decision extends to all Java versions below Java SE 6 update 31 and Java SE 7 update 3, so all browser users who do not routinely update Java in their browsers will be affected.

What is the Java Plug-in?

The Java Plug-in is a software product that serves as a bridge between a browser and an external JRE. A developer instructs the browser to use this external JRE by placing special HTML tags on a Web page. The Java Plug-in lets a browser run Java applets that access (within the limits of Java's security model) all of the features of the external JRE.

Following the announcement, it was argued that Java should be eliminated from the browser altogether. As a Java developer with a long investment in client-side development, I agree. Eliminating the Java Plug-in would officially end the era of applets, but that era is already over. Applets have always been cumbersome to deploy, and in today's world that is more embarrassing than it's ever been. Furthermore, the Java sandbox is an outdated security mechanism. Its requirement that applets be digitally signed causes more trouble than it's worth.

Java developers still using applets today are investing in outdated technology that seals our dependency on browser vendors. We'd be better off building better Java applications with JavaFX, or using the browser vendor's technology of choice: HTML5/JavaScript/CSS3. Neither decision is a bad one, but there is a decision to be made.

If Oracle is really committed to the future of client-side Java, then it should let go of the past. It could start by deprecating the Java Plug-in and reallocating those resources to developing a solid deployment architecture for JavaFX. Client-side Java developers need proper tooling to create JavaFX-based native apps and deploy them on all devices, including desktops, smart phones, and capable feature phones.

Don't write off JavaFX, but do keep demanding improvement

HTML5 is a worthy competitor to JavaFX, but it's not a JavaFX killer. Web apps simply do not replace native apps. Oracle's demonstrated commitment to the future of client-side Java is in JavaFX, so it should continue to sharpen its focus there. So far, the JavaFX roadmap looks promising: Basing JavaFX on the Java language means that developers can write JavaFX apps in any JVM language. Java 8 will include module support that will make it easier to load Java libraries onto slim devices. Java 8's integration of JavaFX 3.0 should feature many UI improvements.

Oracle does need to do more to make JavaFX a solid competitor for building client-side apps, and smoother deployment would be a great place to start. Developers should be able to write apps in JavaFX and compile them into separate packages to be deployed and run in multiple environments: desktops, smart phones, tablets, and JavaFX-enabled feature phones. Proper tooling that leverages the NetBeans, Eclipse, and IntelliJ IDEs could make this happen, and would give JavaFX the muscle to really compete with HTML5.

Jeff Friesen is a freelance tutor and software developer with an emphasis on Java and Android. In addition to writing Java and Android books for Apress, Jeff has written numerous articles on Java and other technologies for JavaWorld, informIT, Java.net, and DevSource. Jeff can be contacted via his website at TutorTutor.ca.

Learn more about this topic