Observations in Migrating from JavaFX Script to JavaFX 2.0

Observations in Migrating from JavaFX Script to JavaFX 2.0

Introduction

Having been available for a few years now, there is a decent body of work written for JavaFX using the JavaFX Script language. With the general availability announcement of JavaFX 2.0 Beta, the natural question arises about converting the legacy code over to the new JavaFX 2.0 platform. This article reflects on some of the observations encountered while porting source code over from JavaFX Script to the new JavaFX API paradigm.

The Application

The program chosen for migration is an implementation of the Sudoku game and serves as a reference application for the book JavaFX – Developing Rich Internet Applications. The design of the program can be divided into two major components: (1) A user interface (ideally suited for JavaFX design) and (2) the puzzle generator. For the context of this article, our primary interest lies in the user interface. The puzzle generator code was lifted from a sourceforge.net project and is written entirely in Java. Regardless which version of the UI we choose (JavaFX Script vs. JavaFX 2.0), no code changes were required for the puzzle generator code.

The original user interface for the JavaFX Sudoku application was written exclusively in JavaFX Script, and as such is a suitable candidate to convert over to the new JavaFX 2.0 model. However, a few notable points are worth mentioning about this program. First off, it was written in the JavaFX 1.1 timeframe, where certain capabilities of the JavaFX framework were as of yet unavailable. Citing two examples, this program creates many of its own UI controls from scratch because the built-in controls were yet to be introduced. In addition, layout of graphical nodes is done in a very manual manner, again because much of the automatic layout capabilities were in flux at the time. It is worth considering that this program was written at a time when most of us were just coming up to speed on this technology. One would think that having the opportunity to recreate this application anew, it would look a lot different from the current version.

Comparing the Size of the Source Code

An attempt was made to convert each of the original UI JavaFX Script source files (suffixed with .fx) over to a Java counterpart. Due to language feature differences, there are a small number of source files which only exist in one version or the other. The table below summarizes the size of each of the source files.

JavaFX Script source file

Number of Lines

Number of Character

JavaFX 2.0 Java source file

Number of Lines

Number of Characters




ArrowKey.java

6

72

Board.fx

221

6831

Board.java

205

6508

BoardNode.fx

446

16054

BoardNode.java

723

29356

ChooseNumberNode.fx

168

5267

ChooseNumberNode.java

302

10235

CloseButtonNode.fx

115

3408

CloseButton.java

99

2883




ParentWithKeyTraversal.java

111

3276




FunctionPtr.java

6

80




Globals.java

20

554

Grouping.fx

8

140




HowToPlayNode.fx

121

3632

HowToPlayNode.java

136

4849

IconButtonNode.fx

196

5748

IconButtonNode.java

183

5865

Main.fx

98

3466

Main.java

64

2118

SliderNode.fx

288

10349

SliderNode.java

350

13048

Space.fx

78

1696

Space.java

106

2095

SpaceNode.fx

227

6703

SpaceNode.java

220

6861

TraversalHelper.fx

111

3095




Total

2,077

79,127


2531

87,800

A few notes about this table are in order:

  • The number of lines in each file was determined by running the Unix ‘wc –l’ command over each file.
  • The number of characters in each file was determined by running the Unix ‘ls –l’ command over each file.
  • The examination of the code could certainly be much more rigorous. No standard formatting was performed on these files.  All comments however were deleted.

There was a certain expectation that the new Java version would require more lines of code than the original JavaFX script version. As evidenced by a count of the total number of lines, the Java version has about 22% more lines than its FX Script counterpart.

Furthermore, there was an additional expectation that the Java version would be more verbose in terms of the total number of characters.  In fact the preceding data shows that on average the Java source files contain fewer characters per line than the FX files.  But that's not the whole story.  Upon further examination, the FX Script source files had a disproportionate number of blank characters.  Why?  Because of the nature of how one develops JavaFX Script code.  The object literal dominates FX Script code.  Its not uncommon to see object literals indented halfway across the page, consuming lots of meaningless space characters.

RAM consumption

Not the most scientific analysis, memory usage for the application was examined on a Windows Vista system by running the Windows Task Manager and viewing how much memory was being consumed by the Sudoku version in question. Roughly speaking, the FX script version, after startup, had a RAM footprint of about 90MB and remained pretty much the same size. The Java version started out at about 55MB and maintained that size throughout its execution.

What About Binding?

Arguably, the most striking observation about the conversion from JavaFX Script to JavaFX 2.0 concerned the need for data synchronization, or lack thereof. In JavaFX Script, the primary means to synchronize data is via the bind expression (using the “bind” keyword), and perhaps to a lesser extent it’s “on replace” cousin. The bind keyword does not exist in Java, so for JavaFX 2.0 a Data Binding API has been introduced as a replacement.

To give a feel for the difference between the two versions of the Sudoku program, the table that follows indicates how many binds were required for each source file. For JavaFX Script files, this was ascertained by simply counting the number of occurrences of the bind keyword. As can be seen, binding had been used frequently in the JavaFX Script version (and does not take into consideration an additional half dozen or so “on replace” triggers). The JavaFX 2.0 program achieves the same functionality as the original JavaFX Script version, yet the equivalent of binding was only needed twice throughout the Java version of the source code.

JavaFX Script source file

Number of Binds

JavaFX Next Java source file

Number of “Binds”



ArrowKey.java

0

Board.fx

1

Board.java

0

BoardNode.fx

7

BoardNode.java

0

ChooseNumberNode.fx

11

ChooseNumberNode.java

0

CloseButtonNode.fx

6

CloseButton.java

0



CustomNodeWithKeyTraversal.java

0



FunctionPtr.java

0



Globals.java

0

Grouping.fx

0



HowToPlayNode.fx

7

HowToPlayNode.java

0

IconButtonNode.fx

9

IconButtonNode.java

0

Main.fx

1

Main.java

0

Main_Mobile.fx

1



SliderNode.fx

6

SliderNode.java

1

Space.fx

0

Space.java

0

SpaceNode.fx

9

SpaceNode.java

1

TraversalHelper.fx

0



Total

58


2

Conclusions

As the JavaFX 2.0 technology is so new, and experience with the platform is the same, it is possible and indeed probable that some of the observations noted in the preceding article may not apply across other attempts at migrating applications. That being said, this first experience indicates that the migrated Java code will likely be larger, though not extensively so, than the original Java FX Script source. Furthermore, although very important, it appears that the requirements for data synchronization via binding, may be significantly less with the new platform.

Comments:

I am not sure that the JavaFX 2.0 version of Sudoku program does require very fewer bindings than 1.1
What makes that possible?

Posted by yoshiki on June 26, 2011 at 07:45 PM EDT #

As per a previous blog entitled, Why I like the New JavaFX, here's some more rationale:

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.

Posted by guest on June 27, 2011 at 09:29 AM EDT #

Hi Jim,
Thanks for the lovely post. However, is there any way we could get hold of the converted code (in Java)? I'm migrating a big application from 1.3 to 2.0 and looking at your converted code would be a big help.
Thanks.

Posted by Saurabh on August 31, 2011 at 08:59 AM EDT #

Here's the current situation: Even though JavaFX 2.0 is in public Beta, the API is still in flux, so much so that every time I pull down a newer internal build, something breaks. The code used for this test is hopelessly obsolete with regards to the latest API. The good news (I think) is that we are hopefully coming to and end to all these changes, where we'll draw a line in the sand and say the API is frozen. But that hasn't happened yet. Once it does, then, given some time, I'll migrate over to the latest stable API and post.

Posted by Jim Connors on August 31, 2011 at 09:58 AM EDT #

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