X

Topics and trends related to the Java ecosystem with occasional random rants.

  • Sun
    November 28, 2010

Why I like the New JavaFX

James Connors
Principal Solutions Consultant

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.

Join the discussion

Comments ( 6 )
  • Thomas Wednesday, December 1, 2010

    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.


  • James Connors Wednesday, December 1, 2010

    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/


  • Emmanuel Friday, December 3, 2010

    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?


  • James Connors Friday, December 3, 2010

    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/


  • Emmanuel Saturday, December 4, 2010

    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.


  • Tony Anecito Thursday, December 9, 2010

    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


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.