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.