Jim has posted 16 posts at DZone. View Full User Profile

Why I Like the New JavaFX

11.29.2010
| 8429 views |
  • submit to reddit

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.

Published at DZone with permission of its author, Jim Connors.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Bob Smith replied on Mon, 2010/11/29 - 10:18pm

I imagine the reason Sun decided to implement a new language for JavaFX is due to backward compatibility issues that are seriously hampering the language.   At the top of the list of Java's lack of closures.

Instead of dealing with the limitations of a 15-year old language, Sun could implement new features such as closures and data binding, as well as graphical-related concepts without fear of breaking any backward compatibility.

Without the JavaFX language, developers will have to code callbacks as anonymous inner classes, data bindings as method calls, and graphical objects more verbosely.   

The lack of closures in Java really hurts its usefulness as a GUI programming language, and some say the SAM lambda feature doesn't go nearly far enough in addressing the lack of closures, since it doesn't seek to reform Java's type system, and SAM closures won't be declared as specific types but must implement interfaces.   Sun's decision to use primitive types instead of objects right off the bat is hurting the language to this day.

Dummy Akkount replied on Tue, 2010/11/30 - 9:06am

I really pity those that think JavaFX is still relevant in 2010. Not only are you wasting your (and possibly your employer's) time, you are also delusional.

First, Adobe has won this battle long time ago. Microsoft tried to attack this market with Silverlight (an actual shipping product with great IDE support) but it has gotten them nowhere.

Second, HTML5 and javascript are the way to go. One should really master those two as they are everywhere.

JavaFX is a prime example of how Sun for the past decade has no clue what they're doing. All the great development in Java (ORM, DI, web frameworks) has happened elsewhere. Oracle (with JDK7,8 and their attitude towards community) is following their step.

Mladen Girazovski replied on Tue, 2010/11/30 - 9:25am in response to: Dummy Akkount

I really pity those that think JavaFX is still relevant in 2010. ..

I have to strongly disagree, the word "still" is implying that JavaFX has been relevant at some point in the past, which is simply not true.

I agree with the rest of your statement.

Bob Smith replied on Tue, 2010/11/30 - 8:54pm

JavaFX isn't about competing with Adobe for all enterprise RIA business.  It's about providing an RIA framework for Java shops, and to decomission Swing, which is bogged down by the same legacy issues as the Java language.

As for the assertion that HTML 5 and JavaScript are good enough for serious RIA development, I say they are most absolutely not for several reasons:

1)  Lack of functionality, especially for the enterprise, which needs rich interfaces to be filthy rich.

2)  Lack of a common runtime.   Even if IE 6 were wiped out tomorrow, each of the competing browsers has its own quirks that must be coded for.   Flash/Silverlight/Java represent a common runtime that developers can target.

3) Lack of tooling.  Good developer tools on the order of Eclipse/Netbeans/Visual Studio don't yet exist for HTML 5/Java Script.  It's pretty much a mishmash of tools.

Sun and Oracle don't care about nonsensical platitudes about how Flash/Flex has "already won" and how HTML 5/JavaScript offers some kind of RIA panacea.   They know a lot more than you do.

Jim Connors replied on Tue, 2010/11/30 - 11:51pm

One important fact I failed to mention in the article is that although Oracle has effectively ceased its work on  JavaFX Script, ongoing development is still taking place in the open source under project Visage.  Stephen Chin, principal on the project and JavaFX author, mentions that some of the shortcomings of the language, many of them mentioned above, are being addressed. 

For more info, check out http://code.google.com/p/visage/

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.