Why I like the New JavaFX

I have a vested interest in seeing the original JavaFX Script based platform prosper. As an early adopter of this technology, a good portion of my life these past few years has been spent developing, blogging and even co-authoring a book on the subject. So when the inevitable demise of JavaFX Script was formally announced, those of us intimately involved did not take it lightly.

Perhaps not unlike yourselves, I’ve viewed the plans to morph JavaFX into a Java API with a bit of skepticism. The new resulting coding paradigm is unquestionably less stylish than its predecessor and can be downright verbose. But the new way grows on you. Having the privilege to experiment with early versions, I’ve come to like the new platform. In fact I like it a lot. Here’s why I think the new JavaFX platform is more attractive:

The community has spoken and it doesn’t feel the need for yet another scripting language. The attempt to lure graphics designers into the Java camp by offering a simplified Rich Internet Application environment never really panned out. Why? First, there already exists a wealth of mature, established RIA scripting alternatives. These address much of what designers need and JavaFX Script is not sufficiently different enough. Second, the clamor to provide RIA capabilities in Java comes from the Java community proper, not the graphics artists. These developers have a lot invested in Java and are not interested in learning a new language. What they want is a Java API with RIA capabilities. By making JavaFX a first class citizen of the Java platform, it goes a long way towards meeting these desires.

The JavaFX API is a more universal solution. By building an API in Java, the opportunity for developers of other dynamic languages (like JRuby and JavaScript) to access JavaFX has been made much easier. Moreover, as the trend to host other languages atop the Java Virtual Machine accelerates, these too will profit from this move.

No more mapping between JavaFX Script and Java. A derivative of Java, one of the touted advantages of JavaFX Script is its ability to seamlessly integrate and leverage the wealth of Java code written already. Indeed a very important benefit, Java/JavaFX Script integration is mostly straightforward; however there are subtle differences between both languages that the developer must take into consideration. Mapping primitive Java data types to JavaFX basic types can be an issue. The original JavaFX classes can only extend Java classes that contain a default (no arguments) constructor. Features familiar to Java programmers, like multidimensional arrays, generics, annotations, and multi-threading have no real equivalent in JavaFX Script. Bringing the JavaFX class libraries directly onto the Java platform eliminates all of these concerns. If you want to use some external Java code, just use it.

Superior Development Environment. Attempting to debug JavaFX Script within an Integrated Development Environment is at best a tricky endeavor and at worst a waste of time. Additionally only NetBeans, and to a lesser extent Eclipse, are the only viable JavaFX Script capable IDEs. As the new JavaFX platform is entirely based on Java, not only is debugging support first rate, the option of choosing other Java IDEs opens up considerably.

The new JavaFX results in, for lack of a better term, more predictability. One of the primary JavaFX Script mechanisms used to define and place graphical assets (Nodes) into the scenegraph is the object literal notation. Being static in nature, the notion of a sequential flow of events inside an object literal may not make much sense. To compensate, JavaFX Script introduces the powerful concept of binding. Without question, binding is very elegant, but it comes with a price. It is not uncommon to see liberal and arguably unnecessary use of binding throughout JavaFX script code.

One can argue that bringing JavaFX to Java should lessen, but certainly not eliminate, the need for binding. Rather than defining objects inside a static initializer, JavaFX API objects are created and defined sequentially by constructor and method calls respectively. By defining objects in an order that makes sense, there is potential to eliminate a certain class of dependencies that were previously resolved with binding.

Improved performance. Although by default the JavaFX compiler generates Java bytes codes from JavaFX Script source, there is a command-line option which can be invoked to save the intermediate Java code that is produced as part of the process. A brief perusal of this source shows that even the most humble of JavaFX Script constructs churns out a lot of complicated Java code. Eliminating this overhead is bound to improve performance in many instances. Furthermore, significant optimizations to memory and static footprint as well as startup time are underway. Finally a new lightweight, fast graphics subsystem, dubbed project prism, will obviate the need to utilize older Java graphics windowing systems.

It’s not how you feel, it’s how you look. A superficial difference, but nonetheless one that should not be underestimated, lies in what your code looks like. In JavaFX Script, graphical Nodes are typically placed in the scenegraph via the definition of object literals. Even the least sophisticated of object literal scenegraphs can be grouped and nested several levels deep, each nesting moving the source code further to the right. Some JavaFX Script code is so indented it leaves little room to write anything of consequence without having to split a line of code into two or more lines.

It didn’t take very long to come up with these talking points. No doubt, as development progresses and more folks jump on board, additional benefits will become apparent.

Comments:

Will there be a migration tool from JavaFX script to JavaFX with Java? The situation right now is that no one wants to write JavaFX script any more since Oracle announced to kill it, yet the new version can not be used yet, even as a beta.

Posted by Thomas on December 01, 2010 at 04:22 AM EST #

I know of no migration tool in the works. In case you were unaware, ongoing development of JavaFX Script has been taken up with the open source project called Visage. Plans call for the project to address some of the shortcomings mentioned above. For more info check out http://code.google.com/p/visage/

Posted by James Connors on December 01, 2010 at 11:19 AM EST #

As a Swing programmer, I wasn't really tempted to learn JavaFX, and found it less and less appealing once I discovered programs weren't even compatible from a version to the next. I'm more interested by learning a new Java API but I have to learn everything about JavaFX. Please give us more links.
When will it be available?
Is there some kind of demo that shows how code will look like?
Will it be available in Java SE?
Any other links that you feel relevant?

Posted by Emmanuel on December 03, 2010 at 01:25 AM EST #

One big difference between philosophies at Sun and Oracle is that Oracle is very concerned about how any future product announcement might adversely affect current opportunities. As such, Oracle is much more guarded about futures. Your best bet is to look at the published roadmap information supplied on the javafx website at http://javafx.com/roadmap/

Posted by James Connors on December 03, 2010 at 02:14 AM EST #

Thank you for your no answer (no offense, I understand that you can't tell more that you're allowed to ;-).
My bet is that I'll wait for something more substantial than a roadmap.

Posted by Emmanuel on December 04, 2010 at 02:52 AM EST #

Hi,
Thanks for the article. I use Swing for Rolling Thunder and use the defualt Nimbus and offer additional skins (Substance). I like the look and feel of JavaFX and would like to see it adopted by swing. I am not sure if Oracle is headed in that direction. Any thoughts on that?
I would like the ability to use the caption area for buttons for example. Basically have a more area efficient UI.

Thanks,
Tony Anecito
Founder/CEO
MyUniPortal (2010 JavaOne Duke Award)
http://www.myuniportal.com

Posted by Tony Anecito on December 09, 2010 at 03:34 AM EST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Jim Connors

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today