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! 

Wednesday Nov 04, 2009

Consumer Electronics: Your Utility Company's Best Friend

If you're reading this article, the chances are real good that your home is full of electronic gadgets.  Moreover many are permanently plugged into wall sockets.   Having recently purchased a P3 International P4460 Kill A Watt EZ power meter, I've been running around getting a feel for how much energy some of these common components use.

For this first table, I wanted to see how much energy was being consumed by audio/visual components that were plugged into the wall, but not powered on.  Indeed some of these numbers are eye-opening:

 Device  Watts consumed (powered off)
Visio 22" LCD HDTV (circa 2007)  1.58
Visio 32" LCD HDTV (circa 2009)  1.18
25" RCA Tube TV (circa 1990)  4.17
Marantz AV Surround Reveiver SR7200  2.79
Marantz CD Changer CC9100  1.43
Marantz DVD Player DV6200  3.60
Boston Micro90pv II Subwoofer 14.53
Microsoft Xbox 360  3.64
Nintendo Wii  2.70
Sony PlayStation 2  0.67
Scientific Atlanta Explorer 4250HD set top 17.27
Scientific Atlanta Explorer 8300HD DVR set top 20.00

The granularity of the P4460 is hundredths of kilowatt-hours, which means that in order to get a decent reading on a low-power device, you've got to leave it attached for a while.  No doubt some of these measurements could be more accurate, but I think you get the point.  Of note:

  1. The 4 components that comprise the audio system consume over 22 watts all day, every day 24x7.
  2. As set top boxes gain more functionality (e.g. DVR), they suck up even more power.   At this rate, you'd think the power utility would subsidize the cable companies to get as many of these things installed as possible.
  3. All told, the devices in the preceding table consume an amount of energy similar to a 75 watt incandescent light bulb being left on all the time.

For the most part, these components are non-critical, and one could argue that some (e.g  the stereo) should be connected to a power strip with an on/off button. This should not pose much of an inconvenience.  However, it's a completely different story when it comes to the video components.  When powered cycled, set top boxes take forever to reach full functionality as they reboot over the cable network.  And televisions, if left untethered to electric power for too long, go through this whole channel search sequence when they're powered up.  In short, when it comes to video, you're currently stuck with paying the hidden price of "convenience".

For the computer nerd in us, here's a table comprising some of the computer/network-related components that are left on 24x7.

 Watts Consumed
Belkin Wireless G Router
Motorola SBV5120 SURFboard Cable Modem
Netgear ProSafe 16 port 10/100 Switch (FS116)
HP Photosmart c6280 printer (circa 2008) (networked)
HP Laserjet 4P (circa 1994)
Canon ImageCLASS MF4270 all-in-one laser printer (networked) (circa 2009)
Fit-PC Slim with external USB hard disk (network file server)

A decade ago, devices like those listed above were virtually non-existent in the home.  So what's the cost of being Internet ready anytime, anywhere?  About 40 watts all day and all night. Some final points:

  1. In general, carefully consider keeping around older gadgets.  The circa 1990s devices definitely use more energy than their newer, more functional counterparts.
  2. Notice no computers are included.  You know you have more than one, some (present company included) have way more than one.  Let's hope you're turning these off or at least putting them to sleep at night!

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.

Monday May 11, 2009

You Are What You Eat?

So you may ask, what effect does the food we eat have on our blood pressure?  My experience, documented below, won't likely hold up to whole lot of scientific scrutiny, but it's good enough lesson for me.

A combination of poor eating habits and genetics lands me in that ever-increasing group of individuals who have high blood pressure.  At first I was what you might consider borderline hypertensive.  Being thin and active, in conjunction with my doctor, we only monitored my levels to make sure they didn't get worse.  Unfortunately they did.

In an attempt at avoiding medication, I started seriously watching my sodium intake.  The resulting change in blood pressure was noticeable in pretty short order.   See the table below for daily readings for the last two weeks.  In general, I try to take my reading at or around 8:00AM if possible.

Having spent my whole life eating pretty much what I please, it's not easy to make this lifestyle change.   But with the help of loved ones, things have been going quite well.  But then came Mother's day (5/10).   A combination of brunch with my parents and dinner with my in-laws put the kabash on any diet plans.  I knew this would happen, and was frankly looking forward to the feast.  It only took one day for my pressure to skyrocket.  Amazing.  But man did I enjoy eating the waffles, bacon, crumbcake, bagels, Mimosas (Orange Juice and Champagne) cookies, macaroni, meatballs, turkey, chocoloate cake, Coke, Espresso, wine, Sambuca and Cognac to name a few.

 Date  Time  Blood Pressure
 4/29 8:01 AM
 4/30 8:19 AM
 5/1 8:18 AM
 5/2 7:48 AM
 5/3 9:22 AM
 5/4 7:53 AM
 5/5 8:20 AM
 5/6 7:16 AM
 5/7 6:19 AM
 5/8 6:56 AM
 5/9 7:48 AM
 5/10 9:14 AM
 5/11 7:56 AM

Back to the bland diet, that is, until the next feast.

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.

Monday Apr 06, 2009

Node Count and JavaFX Performance

In a recent blog entry entitled Best Practices for JavaFX Mobile Applications (Part 2), Michael Heinrichs espouses that keeping the scenegraph as small as possible helps JavaFX applications perform optimally. Regardless what version of JavaFX you're using, this is sage advice.  Having spent some time trying to create components for a scoreboard-like application, I was concerned over the amount of CPU time being consumed by the clock component pictured directly below.

You can click on the preceding image to run this mini application via Java WebStart.   By placing your mouse over any of the digits and typing in, via keyboard input, a valid number, you can set the clock.  Clicking on the "START/STOP" text will toggle the clock on and off.  Like many scoreboard clocks, when the time remaining is less than one minute, 10ths of seconds are displayed.  It is during this phase, when digits are being updated every tenth of a second, that this application can be especially taxing.  You can imagine how troublesome this clock might be if it were to be part of say a hockey scoreboard which could have an additional 4 penalty clocks ticking simultaneously.

The major factor affecting performance appears to be the sheer number of nodes in the scenegraph that require recalculation for every clock tick.  For this first implementation, each of the five clock digits is comprised of 27 BulbNodes, (my naming) which are switched on or off depending upon what value needs to be displayed.

In an effort to see how decreasing the node count might effect performance, this second implementation of the clock component uses the same underlying framework, except that each digit is now composed of 7 LED SegmentNodes (my naming again) instead of 27 BulbNodes.   You can run this version of the clock component by clicking on the image that follows.

For our final example, in order to truly minimize node count, each digit is represented by a single ImageView node. When the value of a digit changes, a new Image is displayed.  By caching all of the possible digit values (blank, 0-9) you can very quickly switch images.  No doubt, prettier images can be created, but I think you get the point.  Click on the image that follows to try this version.

The Results

The slower the compute platform, the more pronounced the differences in performance should be.  Thinking along those lines, a very modest 1.4 GHz Pentium M laptop was chosen as the test environment to compare CPU utilization for these applications.  OpenSolaris provides an easy-to-use well-known command-line tool called vmstat(1M), which was chosen as the mechanism to analyze the individual applications. In contrast, the Performance Tab which is part of the Windows Task Manager, seemed to produce wild performance variations.

For each run,  the clocks were set to one minute, and run until the time expired.  The data shown below represents the average CPU utilization, after startup, for each of the three implementations.  In particular we'll look at the following fields returned by vmstat:

  • 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%.

Number of Nodes per Digit
CPU Utilization
Implementation 1: BulbClockNode
 27 BulbNodes
 us: 22%  sy: 2%  id: 76%
Implementation 2: LEDClockNode
 7 SegmentNodes
 us: 9%    sy: 2%  id: 89%
Implementation 3: ImageClockNode
 1 ImageNode
 us: 3%    sy: 2%  id: 95%

The JavaFX engineering team is well aware of this limitation, and hopes to redesign the underlying scenegraph plumbing in the future.  Regardless, it's still a good idea to take into consideration the size of your scenegraph.

JavaFX book status:  Our upcoming book, JavaFX: Developing Rich Internet Applications, is in copy edit.  Coming soon: Rough cuts of certain chapters will be available on Safari.

Tuesday Mar 24, 2009

Hooray! Acrobat Reader for [Open]Solaris x86

Today truly marks a milestone in the history of Solaris for the x86/x64 platform.  One of the most ubiquitous applications, Adobe Reader (notably Acrobat), is now available on [Open]Solaris for both Sparc and x86.

It's been a long time coming, one argument for the lack of Solaris x86 support till now was that [Open]Solaris didn't have the critical mass.  That's a hard one to swallow for the following reasons:

  • There's been a Solaris Sparc version for a long time.  Solaris x86 downloads outnumber Sparc downloads by a large factor.
  • Versions for AIX and HP-UX, which have a significantly smaller installed base, are available.  Maybe IBM and HP payed a lot of money for this?
  • Until recently there were versions even for the likes of OS/2 and UnixWare.

Perhaps open source alternatives are becoming good enough to pose a threat?  Whatever the reason, we welcome the arrival of Acrobat Reader and Adobe's change of heart.

You can get your copy here.

Happy Downloading!

Thursday Mar 19, 2009


It is within our nature, even in the most infinitesimal way, to leave our mark on this world before we exit it.  I'd like to coin the following term, heretofore unseen in the JavaFX space, and submit it as my humble contribution to the human collective:

bindstorm \\'bïnd•storm\\ (noun): condition where a multitude of JavaFX bind recalculations severely hampers interactive performance

Yeah, I know, using the word you wish to define inside its definition is bad, but there is precedent for this: (1) Fancy-schmancy, hoity-toity college dictionaries do it all the time. (2) Mathematicians and computer scientists call this recursion: that mysterious concept which developers use to impress others of their programming prowess.

Don't get me wrong, JavaFX binding is incredibly powerful.  Heck, we dedicated a whole chapter to it in our soon-to-be-released book JavaFX: Developing Rich Internet Applications.  But binding does come with a price, and like most anything else, over-consumption can lead to abuse.

Consider this use case: you've got a JavaFX application with dozens or maybe even hundreds of Nodes that are part of the scenegraph.  Each of the Nodes are ultimately sized and positioned in proportion to height and width instance variables that are passed on down.  If you define width and height at startup and have no interest in a resizeable interface, then you stand a good chance of avoiding the use of many bind expressions.  The one potential twist here is that if you're sincerely interested in a non-resizeable application, but want it to consume the entire screen, what do you do?  As screens come in all shapes and sizes, you may not know what the resolution is at start time.  JavaFX has an elegant solution for this which uses binding.

Here's a simple application which defines a Rectangle and Circle that fill the entire screen.  You can click anywhere within the Circle to exit the application.  Notice the number of binds required to get this to work.

import javafx.stage.\*;
import javafx.scene.\*;
import javafx.scene.shape.\*;
import javafx.scene.paint.\*;
import javafx.scene.input.\*;

function run() : Void {
    var stage: Stage = Stage {
        fullScreen: true
        scene: Scene {
            content: [
                Rectangle {
                    width: bind stage.width
                    height: bind stage.height
                    fill: Color.BLUE
                Circle {
                    centerX: bind stage.width / 2
                    centerY: bind stage.height / 2
                    radius: bind if (stage.width < stage.height) then
                            stage.width / 2 else stage.height / 2
                    fill: Color.RED
                    onMouseClicked: function(me: MouseEvent) {

Imagine what this would look like if you had lots of complex custom components with many more dependencies on height and width.  In addition to the potential performance impact, this could be error-prone and cumbersome to code.  To avoid the over usage of binding and the potential for a bindstorm, applications of this sort could be re-written as follows:

import javafx.stage.\*;
import javafx.scene.\*;
import javafx.scene.shape.\*;
import javafx.scene.paint.\*;
import javafx.scene.input.\*;

function run() : Void {
    var AWTtoolkit = java.awt.Toolkit.getDefaultToolkit ();
var screenSizeFromAWT = AWTtoolkit.getScreenSize (); Stage { fullScreen: true scene: Scene { content: [ Rectangle { width: screenSizeFromAWT.width height: screenSizeFromAWT.height fill: Color.BLUE } Circle { centerX: screenSizeFromAWT.width / 2 centerY: screenSizeFromAWT.height / 2 radius: if (screenSizeFromAWT.width <
screenSizeFromAWT.height) then
screenSizeFromAWT.width / 2
else screenSizeFromAWT.height / 2 fill: Color.RED onMouseClicked: function(me: MouseEvent) { FX.exit(); } } ] } } }

We achieve the same effect as the first example by first making a call to a method in the java.awt.Toolkit package.  With this information we can statically define our scenegraph without the use of binding.

There is one caveat to this solution.  As the AWT (Advanced Windowing Toolkit) is an integral part of Java SE, this code should be portable across all JavaFX desktops.  However, if you wish to deploy a JavaFX Mobile solution, the AWT calls would likely change.  Is there a mechanism that might work across both models?

As a final thought, while we're on this theme of coining terms, my compadres Jim Clarke and Eric Bruno, co-authors of the aforementioned JavaFX book, jokingly asked what word could be used to describe this scenario:

"Condition where binds lead to binds that leads back to the original bind, ending up in a Stack fault?"

BindQuake? BindTsunami? Bindless? BindSpin? BindHole (BlackHole)? BindPit?


Tuesday Feb 24, 2009

Registering Multiple Actions (or Handlers) in JavaFX

Java developers, especially those performing any type of GUI work, will ultimately encounter Java's event-driven programming paradigm.  In short, if programmers want to act upon some kind of event they bundle up a chunk of code into a Java method, typically referred to as a handler, and register the handler with that event.  Whenever that event occurs, the handler code will automatically be executed.

JavaFX provides a similar mechanism.  For a straightforward example, the code below defines a simple timer in JavaFX with a resolution of 1 second.  Each time a second expires, the function specified by the action instance variable will be executed.  Here's what it looks like:

import javafx.animation.\*;

public class SimpleTimer {
    public def timeline = Timeline {
        repeatCount: 5
        interpolate: false
        keyFrames: [
            KeyFrame {
                time: 1s
                action: function () : Void {

Adding a run() function, as follows, to the bottom of this source will enable you run an instance of this timer:

function run() : Void {
    var s = SimpleTimer{};

The output from this run looks like this:


It's all well and good if you only need a single action.  What if you wanted to perform multiple actions and/or dynamically add or subtract a number of actions?  We can enhance our previous SimpleTimer class to dynamically register and unregister handlers by taking advantage of two of JavaFX's features: sequences and function pointers.

Our new class provides more flexibility:

  • It defines an instance variable called duration, which enables the user to specify the resolution of a clock tick at object instantiation.
  • It defines two additional public functions called registerHandler() and unRegisterHandler() which take a function pointer (a handler) as an argument.  By registering a handler, the function will be included in the list of handlers to be executed each time the specified duration expires.
  • A handler is registered by inserting it's function pointer argument into an internal sequence of function pointers called handlers[].
  • A handler is similarly unregistered by deleting it's function pointer argument from the handlers[] sequence.
  • The action instance variable, which is part of the KeyFrame instance, now calls an internal function called runHandlers()runHandlers() sequentially executes the functions found in the handlers[] sequence.
Here's the new class:
import javafx.animation.\*;

public class Timer {
     \* User-definable:  specifies the length of time for one cycle.
    public var duration = 100ms;

    public def timeline = Timeline {
        repeatCount: Timeline.INDEFINITE
        interpolate: false
        keyFrames: [
            KeyFrame {
                time: duration
                action: runHandlers

    // Holds the list of handlers to run
    protected var handlers: function() [];

     \* Add the function, represented by the handler argument, to the list
     \* of handlers.  These will run when the elapsed time, specified
     \* by the duration instance variable, expires.
    public function registerHandler(handler : function()) : Void {
        for (func in handlers) {
            if (handler == func) {
                return;  // handler already registered -- skip
        insert handler into handlers;

     \* Remove the function, represented by the handler argument, from
     \* the list of handlers.
    public function unRegisterHandler(handler : function()) : Void {
        delete handler from handlers;

    protected function runHandlers() : Void {
        for (handler in handlers) {

To test this class out, we'll add a run() function at the script level.  The run() function creates a Timer instance and registers two handler functions, decrementTenthsRemaining() and processTicks().  Here's the code:

function run() : Void {
    var t = Timer {};
    var tenthsRemaining = 100;
    var decrementTenthsRemaining = function() : Void {
        tenthsRemaining -= 1;
    var processTick = function() : Void {
        if (tenthsRemaining mod 10 == 0) {
            println("seconds left: {tenthsRemaining / 10}");
        if (tenthsRemaining == 0) {

And this is the output from the run:

seconds left: 9
seconds left: 8
seconds left: 7
seconds left: 6
seconds left: 5
seconds left: 4
seconds left: 3
seconds left: 2
seconds left: 1
seconds left: 0

Shameless Promotion:  Keep up to date with the latest status of our upcoming JavaFX Book entitled JavaFX: Developing Rich Internet Applications at


Jim Connors-Oracle


« April 2015