Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

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

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

By Jeff Friesen, JavaWorld.com, 04/16/12

Page 2 of 3

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).

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.