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 3 of 3

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.

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.

About the author

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.

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