Friday Aug 19, 2011

Serial Port Communication for Java SE Embedded

The need to communicate with devices connected to serial ports is a common application requirement.  Falling outside the purview of the Java SE platform, serial and parallel port communication has been addressed with a project called RXTX.  (In the past, you may have known this as javacomm).  With RXTX,  Java developers access serial ports through the RXTXcomm.jar file.  Alongside this jar file, an underlying native layer must be provided to interface with the operating system's UART ports.  For the usual suspects (Windows, Linux/x86, MacOS, Solaris/Sparc), pre-compiled binaries are readily available.  To host this on an alternative platform, some (hopefully minimal) amount of work is required.

Here's hoping the following notes/observations might aid in helping you to build RXTX for an embedded device utilizing one of our Java SE Embedded binaries.  The device used for this particular implementation is my current favorite: the Plug Computer.

Notes on Getting RX/TX 2.1-7-r2 Working on a Plug Computer

1. At this early juncture with Java 7, be wary of mixing Java 7 with code from older versions of Java. The class files generated by the JDK7 javac compiler contain an updated version byte with a value that results in older (Java 6 and before) JVMs refusing to load these classes.

2. The RXTX download location has binaries for many platforms including Arm variants, but none that worked for the Plug Computer, so one had to be built from source.

3. Using the native GCC for the Plug Computer and the RXTX source, binaries (native shared objects) were compiled for the armv5tel-unknown-linux-gnu platform.

4. The RXTX "stable" source code found at the aforementioned site is based on version rxtx 2.1-7r2.  This code appears to be pretty long in the tooth, in that it has no knowledge of Java 6.  Some changes need to be made to accommodate a JDK 6 environment.  Without these modifications, RXTX will not build with JDK6

SUGGESTED FIX, most elegant, not recommended:
Edit the file in the source directory and look for the following:

    case $JAVA_VERSION in

and change the second line to:


Upon modification, the script found in the rxtx source directory must be re-run to recreate the ./configure script.  Unfortunately, this requires loading the autoconf, automake and libtool packages (plus dependencies) and ended up resulting in libtool incompatibilies when running the resultant ./configure script.

Instead, edit ./configure and search for the occurrences (there are more than one) of

    case $JAVA_VERSION in

and change the second line to:


Run './configure', then 'make' to generate the RXTXcomm.jar and platform specific .so shared object libraries.

5. You may also notice in the output of the make, that there were compilation errors for source files which failed to find the meaning of "UTS_RELEASE".  This results in some of the shared object files not being created.  These pertain to the non-serial aspects of RXTX.  As we were only interested in, this was no problem for us.

6. Once built, move the following files into the following directories:

    # cd rxtx-2.1-7-r2/
    # cp RXTXcomm.jar $JAVA_HOME/lib/ext
    # cd armv5tel-unknown-linux-gnu/.libs/
    # cp $JAVA_HOME/lib/arm
    # cd $JAVA_HOME/lib/arm
    # ln -s

Now Java applications which utilize RXTX should run without any java command-line additions.

The RXTXcomm.jar file can be downloaded here.  To spare you the effort, a few pre-built versions of are provided at this location:

If you've gone through this exercise on any additional architectures, send them my way and I'll post them here.

Tuesday Jun 21, 2011

Observations in Migrating from JavaFX Script to JavaFX 2.0

Observations in Migrating from JavaFX Script to JavaFX 2.0


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 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






































































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”













































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.

Wednesday Jun 01, 2011

Java SE Embedded Development Made Easy

Slowly but surely this old dog (who can learn new tricks, but at a snail's pace) came to the realization that although still quite relevant, a whole generation of people prefer not to read lengthy writings, but would rather digest information in small pieces using new media formats.  Thus the rationale for the following blog...

Certainly no thespian when it comes to public speaking, I will say this:  based upon my experience demonstrating Java SE on embedded devices, people have definitely expressed genuine interest.  Maybe it was the cool device (i.e. Plug Computer) which was used, or maybe this combination of hardware and software inspired the audience to think of the possibilities presented by this new platform.  Either way, I thought it might make sense to capture a shortened presentation/demonstration session.  Following is a 30 minute session broken down into two 15 minute videos (because YouTube only allows videos of 15 minutes or less for mere mortals). They aim to demonstrate how developers already familiar with the Java SE development paradigm can leverage that knowledge to seamlessly develop on very capable embedded processors.  Happy viewing!

Tuesday Mar 15, 2011

The Unofficial Java SE Embedded SDK

Developing applications for embedded platforms gets simpler all the time, thanks in part to the tremendous advances in microprocessor design and software tools.  And in particular, with the availability of Java SE compatible Virtual Machines for the popular embedded platforms, development has never been more straightforward.

The real beauty behind Java SE Embedded development lies in the fact that you can use your favorite IDE (Eclipse, NetBeans, JDeveloper ...) to create, test and debug code in the identical fashion in which you'd develop a standard desktop or server application.  When the time comes to try it out on a Java SE Embedded capable device, it's just a matter of shipping the bytecodes over to the device and letting it run.  There is no need for complicated emulators, toolchains and cross-compilers.  The exact same bytecodes that ran on your PC, run unmodified on the embedded device.

In fact, because all versions of Java SE (embedded or not) share a considerable amount of common code, we have plenty of anecdotal evidence which supports the notion that behavior -- correct or incorrect -- manifests itself identically across platforms.  We refer specifically here to bugs.  Now no one wants bugs, but believe it or not, our customers like the fact that behavior is consistent across platforms whether it's right or not. "Bug for bug compatibility" has actually become a strong selling point!

Having espoused the virtues of transparently developing off device, many still wish to test and debug on-device regularly as part of their development cycle.  If you're the touchy/feely type, there are ample examples of affordable and supported off-the-shelf devices that could fit the bill for an Unofficial Java SE Embedded SDK.  One such platform is the Plug Computer.

The reference platform for the Plug Computer is supplied by Marvell Technology Group. Manufacturers then license the technology from Marvell to create their own specific implementations.  Two such vendors are GlobalScale and Ionics.  These are incredibly capable devices that include Arm processors in the 1.2GHz to 2.0GHz range, and sport 512MB of RAM and flash.  There are a host of external port and interface options including USB, µUSB, SATA, GBE, SD, WiFi, ZigBee, Z-Wave and soon HDMI.  Additionally, several Linux distros are available for these systems too.  The typical cost for a base model is $99, and perhaps the most disruptive aspect of these systems, they consume on average about 5 watts of power.

Alongside developing in the traditional manner, the ability to step through and examine state on these devices via remote debugging comes as a standard feature with the Java SE-E VM.  Furthermore, you can use the JConsole application from your desktop to remotely monitor performance and resource consumption on the device.

So what would a bill of materials look like for The Unofficial Java SE Embedded SDK?  Pretty simple actually:

That's about it.  Of course, for higher level functionality, you can add additional packages.  For example, Apache runs beautifully here.  Could anyone imagine a large number of these devices acting as a parallel web server?

Thursday Dec 16, 2010

Java SE Embedded Refreshed

As embedded processor designs continue their inexorable drive towards ever increasing capability, the natural desire to utilize more robust software platforms, previously reserved for powerful desktop computers and servers, follows suit.  Recognizing this trend, a version of the Java Standard Edition platform, called Java SE Embedded, has been developed to address this growing market.  In addition to bringing all of the benefits of the ubiquitous Java Standard Edition to the most popular embedded processors, static footprint and memory optimizations have been realized.  To get a feel for some of the space savings, check out this article.

Partly due to the turmoil surrounding the Oracle acquisition of Sun, a refresh of the Java SE Embedded binaries took longer than anticipated.  The new versions are now available for download with these supported configurations.  During that time frame, Java SE-E engineers were able take care of some internal housekeeping which should help for better synchronization of future releases of Java SE with Java SE-E.  In the past, Java SE-E engineers would take a snapshot of the Java Standard Edition code and incorporate their modifications to create a new release, forking from the standard edition source,.  Now, the Java SE-E code is part of the overall Java SE project, such that future Java SE enhancements and bug fixes should now be automatically incorporated into the Java SE-E code base.

The refreshed Java SE-E binaries are based on the Java SE 6 Update 21, and represent substantial security, performance and quality enhancements.  Benchmark tests show that, for example, simply replacing the previous versions of the Java SE-E virtual machines with the latest binaries produces on average about 20% performance gain for the same hardware/OS combination.  Having recently introduced a Just-In-Time (or JIT) compiler to the Android Dalvik Virtual Machine, we thought it would be an interesting exercise to compare performance of Java SE-E to Android on identical hardware.  For a full explanation of the results and methodology, check out Bob Vandette's blog on this topic.  To cut to the chase, for the selected benchmarks, Java SE-E outperforms Android by a factor of two. 

Improving virtual machine performance is a tedious process that takes time.  The bottom line is this:  Java SE Virtual Machine engineers have been at this for a very long time, and have had the benefit of fifteen years of scrutiny from the computer science community.  It will take considerable time and effort for Android to come close to this capability.  In the interim, the Java Virtual Machine performance and quality improvement marches on.

   Next up: Take a look at these pictures.  Based upon Marvell's Plug Computer design, these amazing devices pack a 1+GHz Arm processor with 512MB RAM and consume a minuscule 5 watts of power. They run Java SE-E beautifully.  Combined with an IDE like NetBeans, this makes for an ideal, although unofficial, Java SE Embedded Development Kit.

Sunday Nov 28, 2010

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.

Friday Feb 19, 2010

NetBeans with Subversion, SSH and Windows

Having spent too much time wrestling with the various components required to get NetBeans to access a subversion repository via ssh, I thought it might make sense to jot down a few notes in an effort to save others from such hardships.

NetBeans does have built-in support for CVS, Mercurial and Subversion, but that doesn't mean that these source code revision systems work in a turnkey fashion.  In particular, subversion, especially with Windows, does require some work.

1. To start:
Get the latest JDK.  At the time of this writing it was JDK 6 update 18
Get the latest version of NetBeans,  in this case, NetBeans 6.8.  Install it referencing the latest JDK and furthermore, once inside NetBeans, utilize the update manager to make sure all of your modules are the latest and greatest.

2. Upon starting NetBeans, the menu running along the top of the window has a "Team" entry.  Click on Team and follow Subversion->Checkout (No, you won't be able to check anything out yet). This will bring up an error window which requires you to install a subversion client.

Selecting the default action, which installs a subversion plugin for NetBeans, didn't result in much success. Instead choose the second option: "Install Subversion Commandline Client".  The recommended download for the client points to CollabNet, which is an excellent choice.  Unfortunately the version referred to (v 1.5.5 for Windows) may ultimately prove problematic if you're communicating with a subversion repository that's based on a later version. For this exercise, CollabNet Subversion Command-Line Client v1.6.9 (for Windows) was downloaded and installed.

3. Once Subversion is installed, clicking on Team->Subversion->Checkout again will hopefully bring up a second window which requires you fill in two textfields: (1) A repository URL and (2) a tunnel command.  Let's focus on the tunnel command first.  For windows this requires the equivalent of the Unix/Linux ssh command.  To get this functionality download and install a version of the PuTTY software package.

4. Unlike the Collabnet Subversion Client, PuTTY installation does not put the executables of this package into your PATH.  Make sure to add the PuTTY path (typically C:\\Program Files\\PuTTY) to your PATH.

5. You'll need to edit a subversion configuration file to specify the tunnel command as follows:

C:\\>cd %APPDATA%\\Subversion
C:\\>edit config 

Look for the comment that starts like this:

#ssh = $SVN_SSH ssh

Uncomment it and make it look like the statement below.  The plink.exe executable is part of the PuTTY software bundle:

ssh = $SVN_SSH plink.exe -l user -pw password 

Where user is your remote user name and password is your user's password. You can also use private key authentication if you're uncomfortable with putting your password in the clear, which might look something like:

ssh = $SVN_SSH plink.exe -l user -i C:\\my_private_key.ppk

6. Prior to trying out Netbeans, first connect to your subversion repository via ssh as follows:

C:\\> plink.exe user@host

Prior to running this command, the NetBeans attempt to access the subversion repository hangs, apparently looking for a host fingerprint cache entry.  The plink.exe command above accomplishes its creation, once the correct password is entered.  In addition, it assures that SSH is correctly set up on your Subversion repository server.

7. Returning to the Team->Subversion->Checkout selection from the main NetBeans window, now it's time to fill in the two textfields.  The first entry should look something like this:


for example:


Next should come the tunnel command which should be similar to the entry placed in the %APPDATA%\\Subversion\\config file, namely

plink -l user -pw password

Where, again, user is your remote user name and password is this user's password.

8. With information correctly filled in, and assuming your subversion server is correctly configured, you should be able to begin utilizing subversion through ssh with NetBeans.  For further information, check out:

Good Luck!

Wednesday Feb 10, 2010

JavaFX, Sockets and Threading: Lessons Learned

When contemplating how machine-dependent applications might communicate with Java/JavaFX, JNI or the Java Native Interface, having been created for just such a task, would likely be the first mechanism that comes to mind.  Although JNI works just fine thank you, a group of us ultimately decided against using it for a small project because, among others:

  • Errors in your JNI implementation can corrupt the Java Virtual Machine in very strange ways, leading to difficult diagnosis.
  • JNI can be time consuming and tedious, especially if there's a varied amount of interchange between the Native and Java platforms.
  • For each OS/Platform supported, a separate JNI implementation would need to be created and maintained.

Instead we opted for something a bit more mundane, namely sockets.  The socket programming paradigm has been around a long time, is well understood and spans a multitude of hardware/software platforms.   Rather than spending time defining JNI interfaces, just open up a socket between applications and send messages back and forth, defining your own message protocol.  Following are some reflections on using sockets with JavaFX and Java.  For the sake of simplicity, we'll skip the native stuff and focus on how sockets can be incorporated into a JavaFX application in a thread safe manner.

Sockets and Threading

Socket programming, especially in Java, lends itself to utilizing threads.  Because a socket read() will block waiting for input, a common practice is to place the read loop in a background thread enabling you to continue processing while waiting for input at the same time.  And if you're doing this work entirely in Java, you'll find that both ends of the socket connection -- the "server" side and the "client" side -- share a great deal of common code.  Recognizing this, an abstract class called was created which is responsible for housing the common functionality shared by "server" and "client" sockets including the setup of a reader thread to handle socket reads asynchronously.

For this simple example, two implementations of the abstract GenericSocket class, one called, the other called have been supplied.  The primary difference between these two classes lies in the type of socket they use. uses,  while uses  The respective implementations contain the details required to set up and tear down these slightly different socket types.

Dissecting the Java Socket Framework

If you want to utilize the provided Java socket framework with JavaFX, you need to understand this very important fact:  JavaFX is not thread safe and all JavaFX manipulation should be run on the JavaFX processing thread.1 If you allow a JavaFX application to interact with a thread other than the main processing thread, unpredictable errors will occur.  Recall that the GenericSocket class created a reader thread to handle socket reads.  In order to avoid non-main-thread-processing and its pitfalls with our socket classes, a few modifications must take place.

[1] Stolen from JavaFX: Developing Rich Internet Applications - Thanks Jim Clarke

Step 1: Identify Resources Off the Main Thread

The first step to operating in a thread safe manner is to identify those resources in your Java code, residing off the main thread, that might need to be accessed by JavaFX.  For our example, we define two abstract methods, the first, onMessage(), is called whenever a line of text is read from the socket.  The code will make a call to this method upon encountering socket input. Let's take a look at the SocketReaderThread code inside GenericSocket, to get a feel for what's going on.

    class SocketReaderThread extends Thread {

        public void run() {
            String line;
             \* Read from from input stream one line at a time
            try {
                if (input != null) {
                    while ((line = input.readLine()) != null) {
                        if (debugFlagIsSet(DEBUG_IO)) {
                            System.out.println("recv> " + line);
                         \* The onMessage() method has to be implemented by
                         \* a sublclass.  If used in conjunction with JavaFX,
                         \* use Entry.deferAction() to force this method to run
                         \* on the main thread.
            } catch (Exception e) {
                if (debugFlagIsSet(DEBUG_EXCEPTIONS)) {
            } finally {

Because onMessage() is called off the main thread and inside SocketReaderThread, the comment states that some additional work, which we'll explain soon, must take place to assure main thread processing.

Our second method, onClosedStatus(), is called whenever the status of the socket changes (either opened or closed for whatever reason).  This abstract routine is called in different places within -- sometimes on the main thread, sometimes not.  To assure thread safety, we'll employ the same technique as with onMessage().

Step 2: Create a Java Interface with your Identified Methods

Once identified, these method signatures have to be declared inside a Java interface.  For example, our socket framework includes a interface file which looks like this:

   package genericsocket;

   public interface SocketListener {
       public void onMessage(String line);
       public void onClosedStatus(Boolean isClosed);
Step 3: Create Your Java Class, Implementing Your Defined Interface

With our SocketListener interface defined, let's take a step-by-step look at how the SocketServer class is implemented inside  One of the first requirements is to import a special Java class which will allow us to do main thread processing, achieved as follows:

   import com.sun.javafx.runtime.Entry;

Next, comes the declaration of SocketServer.  Notice that in addition to extending the abstract GenericSocket class it also must implement our SocketListener interface too:

   public class SocketServer extends GenericSocket implements SocketListener {

Inside the SocketServer definition, a variable called fxListener of type SocketListener is declared:

       private SocketListener fxListener;

The constructor for SocketServer must include a reference to fxListener.  The other arguments are used to specify a port number and some debug flags.

       public SocketServer(SocketListener fxListener,
                int port, int debugFlags) {
            super(port, debugFlags);
            this.fxListener = fxListener;

Next, let's examine the implementation of the two methods which are declared in the SocketListener interface.  The first, onMessage(), looks like this:

        \* Called whenever a message is read from the socket.  In
        \* JavaFX, this method must be run on the main thread and
        \* is accomplished by the Entry.deferAction() call.  Failure to do so
        \* \*will\* result in strange errors and exceptions.
        \* @param line Line of text read from the socket.
       public void onMessage(final String line) {
           Entry.deferAction(new Runnable() {

               public void run() {

As the comment points out, the Entry.deferAction() call enables fxListener.onMessage() to be executed on the main thread.  It takes as an argument an instance of the Runnable class and, within its run() method, makes a call to fxListener.onMessage().  Another important point to notice is that onMessage()'s String argument  must be declared as final.

Along the same line, the onClosedStatus() method is implemented as follows:

        \* Called whenever the open/closed status of the Socket
        \* changes.  In JavaFX, this method must be run on the main thread and
        \* is accomplished by the Entry.deferAction() call.  Failure to do so
        \* will\* result in strange errors and exceptions.
        \* @param isClosed true if the socket is closed
       public void onClosedStatus(final Boolean isClosed) {
           Entry.deferAction(new Runnable() {

               public void run() {

Another Runnable is scheduled via Entry.deferAction() to run fxlistener.onClosedStatus() on the main thread. Again, onClosedStatus()'s Boolean argument must also be defined as final.

Accessing the Framework within JavaFX

With this work behind us, now we can integrate the framework into JavaFX.  But before elaborating on the details, lets show screenshots of two simple JavaFX applications, SocketServer and SocketClient which, when run together, can send and receive text messages to one another over a socket.

These JavaFX programs were developed in NetBeans and utilize the recently announced NetBeans JavaFX Composer tool.  You can click on the images to execute these programs via Java WebStart.  Note: depending upon your platform, your system may ask for permission prior to allowing these applications to network.  Source for the JavaFX applications and the socket framework in the form of NetBeans projects can be downloaded here.

Step 4: Integrating into JavaFX

To access the socket framework within JavaFX, you must implement the SocketListener class that was created for this project.  To give you a feel for how this is done with our JavaFX SocketServer application, here are some code excerpts from the project's Main.fx file, in particular the definition of our ServerSocketListener class:

public class ServerSocketListener extends SocketListener {
    public override function onMessage(line: String) {
        insert line into recvListView.items;
    public override function onClosedStatus(isClosed : java.lang.Boolean) {
        socketClosed = isClosed;
        tryingToConnect = false;
        if (autoConnectCheckbox.selected) {

Sparing all of the gory details, the onMessage() method will place the line of text read from the socket in to a JavaFX ListView control which is displayed in the program user interface.  The onClosedStatus() method primarily updates the local socketClosed variable and attempts to reconnect the socket if the autoconnect option has been selected.

To demonstrate how the socket is created, we examine the connectButtonAction() function:

var socketServer : SocketServer;


public function connectButtonAction (): Void {
     if (not tryingToConnect) {
            if (socketClosed) {
                socketServer = new
                tryingToConnect = true;

Whenever the user clicks on the "Connect" button, the connectButtonAction() function will be called.  On invocation, if the socket isn't already open, it will create a new SocketServer instance.  Recognize also that the SocketServer constructor includes an instance of the ServerSocketListener class which was defined above.

To round this out, when the user clicks on the "Disconnect" button, the disconnectButtonAction() function is called.  When invoked, it tears down the SocketServer instance.

   function disconnectButtonAction (): Void {
        tryingToConnect = false;


Admittedly, there's a fair amount to digest here.  Hopefully, by carefully reviewing the steps and looking at the complete code listing, this can serve as a template if you wish to accomplish something similar in JavaFX.

Thursday Dec 31, 2009

GlassFish on a Handheld

Until now, the idea of running something akin to a Java EE application server on a small handeld device would have been greeted with ridicule.  Suddenly that notion doesn't seem so ridiculous when considering the recent technology that's been made available. In particular, the following software advances make this pipe dream more of a reality:

  • Java Standard Edition for Embedded Devices: A series of Java virtual machines are available from Sun for many of the popular embedded hardware/OS platforms. They are not only Java SE compatible, but have been space optimized from a static footprint and RAM perspective to perform in embedded environments.  To give you an idea of some of those optimizations, read this.
  • Java Enterprise Edition 6 Platform Specification and the Web Profile:  The Java EE 6 specification allows for the creation of a subset of the component technologies, called "profiles".  The first of these has been dubbed the Web Profile and contains the common technologies required to create small to medium web applications.  Rather than having to use a full blown Java EE application server in all its glory, you can take advantage of a significantly smaller, less complex framework.
  • Embedded GlassFish: This capability, which is now part of GlassFish v3, enables you to run GlassFish inside your Java application, as opposed to the other way around. Simply put, there is no need install GlassFish or create GlassFish domains in this scenario.  Instead, you include an instance of glassfish-embedded-web.jar in your classpath, make a few GlassFish Embedded API calls from your standard Java application, and voila! you've got a web application up and running.

The Hardware

Rather than opting for one of the many embedded development platforms around (because I'm cheap), I instead decided to investigate what was available from a handheld perspective and see if that environment could be adapted to suit my needs.  After some searching, it looked like the Nokia N810 just might fit the bill.  Courtesy of my buddy Eric Bruno, here's a picture of the N810:

To get a feel for this very capable device, check out Eric's Article. What most interested me was that (1) it has 128MB RAM, (2)  a 400MHz Arm v6 processor, (3) runs a common embedded version of Linux (maemo), (4) has a version of Java SE Embedded (from Sun) which runs fine on this platform and (5) can be had for a relatively affordable price on eBay.

The Operating System

The Nokia N810 is powered by the maemo distribution, an open source platform with a thriving community of developers.  Knowing full well that any attempt to get a web application up and running on this device would stretch its resources to the limit, it was necessary to reclaim as much RAM as possible before starting out.  Here's a description of some of the kludgery involved:

  1. You'll need to download and install some additional applications which can be retrieved from the N810's Application Manager program.  They include: rootsh to enable root access to the device and openssh-client and openssh-server to remotely access the device.
  2. A quick and dirty way to reclaim RAM is to shut down the X-server and kill all of the windowing applications that run in parallel. There are certainly more elegant ways to do this, but in addition to being cheap, I'm lazy too.  What you quickly find out is that any attempt to manually kill off some of these processes results in a reboot of the tablet.  Why? Because by default, the N810 includes a watchdog process that monitors the state of the system.  If it detects any irregularities, it forces a restart.
  3. You can get around this problem by putting the device into what is called "R&D" mode.  This is achieved by downloading the "flasher" utility from and establishing a USB connection between the N810 and your host computer.  Directions for this process can be found here.
  4. Once established, you can invoke the following flasher command:  flasher3.5 --set-rd-flags=no-lifeguard-reset. If this was done successfully, you'll notice that a wrench appears on the tablet screen when it is rebooted.
  5. Once in R&D mode you'll have to remotely ssh into the device via the WiFi connection. The following script called has been provided to kill off the windowing system.  After executing this script, the N810 in effect becomes a headless device.  The only way to communicate with it is through the network.

The Environment

Here's what was required to get the web application up and running:

  1. Ssh into the device.
  2. Download an evaluation copy of Java SE Embedded (ARMv6 Linux - Headless).  For this example the download file was gunzip'ed and untar'ed into the N810 device's /usr directory resulting in a new /usr/ejre1.6.0_10 directory.
  3. Download a copy of glassfish-embedded-web-3.0.jar and place this file in the /usr/ejre1.6.0_10/lib directory.
  4. Modify your PATH variable to include /usr/ejre1.6.0_10/bin and set your JAVA_HOME variable to /usr/ejre1.6.0_10
  5. Create a temporary directory, for this example we'll create a /root/tmp directory.
  6. Compile the following Java source file,,  on a JDK equipped system, which is a slightly hacked version of the original provided by Alexis Moussine-Pouchkine.
  7. Create a glassfish directory under /root/tmp/ and place the compiled Embedded.class file there
  8. Download the sample hello web application, hello.war, and place it in the /root/tmp directory.
  9. Reclaim as much RAM as possible by running the script
  10. Run the web application from inside the /root/tmp directory via the the following command-line invocation:
     # java -cp /usr/ejre1.6.0_10/lib/glassfish-embedded-web-3.0.jar:. glassfish/Embedded hello.war 600

As the N810 cannot match even the most modest of laptops in terms of performance, be prepared to wait around a little before the application is ready.  Check this output to see what is printed out to the console during invocation.

For this run the, N810 was assigned a WiFi IP address of, thus the browser is pointed to that address with port 8888.  Here's what comes up:

And Interacting with the web app produces this:

So this is obviously not ready for prime time, but it does open up a whole lot more possibilities in the near future.

Happy New Year! 

Tuesday Sep 08, 2009

Java RTS 2.2 Early Access 2 Released

Sun recently announced the availability of a second edition of its Java Real-Time System (Java RTS) version 2.2 Early Access.  In a previous blog post, many of the important new features of this release were highlighted.  But I felt compelled to jot down a few additional words, not only because there's a newer version of the software to evaluate, but because there's one interesting component that deserves a little more exposure.

I spent some time today speaking with my compadre, Eric Bruno, author of Real-Time Java Programming: With Java RTS.  He clued me in on the fact that our engineers have performed the daunting task of backporting the JDK 7 client compiler onto Java RTS 2.2.  The engineering team is particularly proud of this feat, and ought to be.  It not only enhances Java RTS performance, it also enables them to better stay in lock step with the latest client hotspot VM developments, something the latest Java SE 6 releases may not entirely do.  For some insight into the engineering trade-offs associated creating this latest version of Java RTS, check out Roland Westerlin's entry.

You can find further information about Java RTS here.  And you can download a version of the software for evaluation here.


Tuesday Aug 11, 2009

JavaFX Scenegraph Performance Revisited

Prior to the release of JavaFX 1.2, an earlier blog post explained how creating an application with a scenegraph containing a large number of nodes can have performance implications.  That entry was subsequently picked up by Java Lobby and recently posted here.  Partly because it was a few months old, it resulted in a rash of, shall we say, interesting comments.

As one commenter pointed out, the initial results represent JavaFX performance in the 1.0/1.1 timeframe.  JavaFX 1.2 has since been released, and performance has improved substantially.  As a case in point, you can click on the image below to run the clock application.  This same application, developed and compiled with JavaFX 1.1 can be run from the previous blog post.  Further instructions are there

This application, compiled with JavaFX 1.2 and run on identical hardware, uses about a third of the CPU resources of the original version.  Specifically, using OpenSolaris vmstat(1M) to monitor CPU usage, the following average statistics were collected for one minute when the clock display is updated every 10th of a second.  The abbreviations have the following meanings:

  • us = percentage usage of CPU time in user space
  • sy = percentage usage of CPU time in system space
  • id = percentage usage of CPU time idling
  • The sum of (us + sy + id) should approximate 100%.

And here are the utilization numbers:

 Version  # Nodes per Digit
 CPU Utilization
 BulbClockNode JavaFX 1.1
 27 BulbNodes
 us: 22%  sy: 2%  id: 76%
 BulbClockNode JavaFX 1.2  27 BulbNodes  us: 7%  sy: 2%  id: 91%

Yes,  performance has improved significantly and will continue to do so.  In fact, the JavaFX team is promising even better results with the advent of JavaFX 1.3 (code named SoMa), when considerable refining of the underlying architecture will take place.  At this stage in it's lifecycle, it's important to "subscribe" to the JavaFX technology.  Advances are coming fast and furious, and they don't promise to slow down anytime soon.

Friday Jul 24, 2009

Getting the JavaFX Screen Size

In a previous post, I showed one way in which you could size the nodes in your scenegraph relative to the screen size without having to use binding, thus eliminating the potential for a bindstorm.  At the time, the suggestion was to get the screen coordiantes via a call to AWT (Advanced Windowing Toolkit) as follows:

 var AWTtoolkit = java.awt.Toolkit.getDefaultToolkit ();
var screenSizeFromAWT = AWTtoolkit.getScreenSize ();

This currently works for JavaFX Desktop deployments but is far from an optimal solution primarily because it is non-portable.  There is no guarantee that AWT will exist-- in fact I'm pretty sure it will not exist -- in the JavaFX Mobile and JavaFX TV space.  So attempting to utilize the code snippet above in a JavaFX Mobile or TV context will result in an error.  Unfortunately at the time of the original post (Java FX 1.1), I didn't know of a better alternative.

With the advent of JavaFX 1.2, this problem is solved.   A new class called javafx.Stage.Screen  is provided which describes the characteristics of the display.  The API definition of the class can be found here.  So now you can query the JavaFX runtime in a portable fashion to get the screen coordinates as follows:

 import javafx.stage.\*;
 //set Stage boundaries to consume entire screen
 Stage {

fullscreen: true width: Screen.primary.bounds.minX as Integer height: Screen.primary.bounds.minY as Integer ... }



Wednesday Jun 10, 2009

Early Access version of Java RTS 2.2 Released

Just in time for the start of JavaOne 2009, Sun released the latest version of its real-time Java platform, Java RTS 2.2, in early access form.  New features of this release include but are not limited to:

  • OS Platform support for Solaris 10 (x86 and Sparc - Update 5 & 6), Red Hat MRG 1.1 and  SUSE Linux Enterprise Real-Time 10 (SP2 Update 4)
  • 64-bit support for the three operating systems mentioned above. In addition, 32-bit support continues to be supported.
  • Faster throughput. Java RTS 2.2 utilizes a new dynamic (JIT) compiler targeted for Java SE 7 which contains several performance improvements including a new register allocator.
  • TSV (Thread Scheduling Visualizer) enhancements.
  • NetBeans plug-in support for Java RTS and TSV. 
  • New Initialization-Time-Compilation (ITC) options including the ability to wild card a set of methods vs listing single methods and support for specifying compilation based on thread type.
  • Auto-tuning and startup improvements made to the Real-time Garbage Collector (RTGC).
  • New documentation including a Java RTS Quick Start Guide to get new users started quickly with minimum programming and configuration.

A 90-day evaluation is available here:  For more detailed information on OS support and new functionality, check out the 2.2 Release Notes.

Tuesday Jun 09, 2009

JavaFX Book Arrives!

Since the beginning, the deadlines set forth for producing our book have been aggressive to say the least.  Ultimately, we wanted them to be physically available for sale at the JavaOne 2009 conference.  These things arrived literally hot off the press, having been flown in the opening day of the show.  This effort was not in vain; the results are in.  According to our friends at Digital Guru, JavaFX was definitely the hot topic of the week and JavaFX - Developing Rich Internet Applications was the best seller.  Furthermore as of 9:52AM Eastern Time 09-June-2009, Amazon reports that its sales rank is a very respectable 21,873.  Not bad for just a few days showing.

These sales were no doubt fueled by Larry Ellison's cameo appearance during the first JavaOne keynote.  Clearly hampered by what he could and could not say due to Oracle's pending acquisition of Sun, Larry went out of his way to promote the future of JavaFX.  He must have mentioned it a half dozen times during his 10 minute or so appearance.  On behalf of Eric and the other Jim, thanks bud.

Friday May 01, 2009

JavaFX Book Available Online at

Our book, entitled JavaFX: Developing Rich Internet Applications, having gone through the copyedit and proof stages, is now available online at Safari @  Please feel free to provide feedback/comments on any aspect of the book that you've chanced to read.  We're still on schedule to have hardcopies available at the Java ONE show which will start on June 2.  If you plan on attending, please stop by the Addison-Wesley/Pearson/SMI Press booth.  Happy reading.


Jim Connors


« April 2014