Monday Nov 05, 2012

Sprinkle Some Magik on that Java Virtual Machine

GE Energy, through its Smallworld subsidiary, has been providing geospatial software solutions to the utility and telco markets for over 20 years.  One of the fundamental building blocks of their technology is a dynamically-typed object oriented programming language called Magik.  Like Java, Magik source code is compiled down to bytecodes that run on a virtual machine -- in this case the Magik Virtual Machine.

Throughout the years, GE has invested considerable engineering talent in the support and maintenance of this virtual machine.  At the same time vast energy and resources have been invested in the Java Virtual Machine. The question for GE has been whether to continue to make that investment on its own or to leverage massive effort provided by the Java community? Utilizing the Java Virtual Machine instead of maintaining its own virtual machine would give GE more opportunity to focus on application solutions.  

At last count, there are dozens, perhaps hundreds of examples of programming languages that have been hosted atop the Java Virtual Machine.  Prior to the release of Java 7, that effort, although certainly possible, was generally less than optimal for languages like Magik because of its dynamic nature.  Java, as a statically typed language had little use for this capability.  In the quest to be a more universal virtual machine, Java 7, via JSR-292, introduced a new bytecode called invokedynamic.  In short, invokedynamic affords a more flexible method call mechanism needed by dynamic languages like Magik.

With this new capability GE Energy has succeeded in hosting their Magik environment on top of the Java Virtual Machine.  So you may ask, why would GE wish to do such a thing?  The benefits are many:

  • Competitors to GE Energy claimed that the Magik environment was proprietary.  By utilizing the Java Virtual Machine, that argument gets put to bed.  JVM development is done in open source, where contributions are made world-wide by all types of organizations and individuals.
  • The unprecedented wealth of class libraries and applications written for the Java platform are now opened up to Magik/JVM platform as first class citizens.
  • In addition, the Magik/JVM solution vastly increases the developer pool to include the 9 million Java developers -- the largest developer community on the planet.
  • Applications running on the JVM showed substantial performance gains, in some cases as much as a 5x speed up over the original Magik platform.
  • Legacy Magik applications can still run on the original platform.  They can be seamlessly migrated to run on the JVM by simply recompiling the source code.
  • GE can now leverage the huge Java community.  Undeniably the best virtual machine ever created, hundreds if not thousands of world class developers continually improve, poke, prod and scrutinize all aspects of the Java platform.  As enhancements are made, GE automatically gains access to these.
  • As Magik has little in the way of support for multi-threading, GE will benefit from current and future Java offerings (e.g. lambda expressions) that aim to further facilitate multi-core/multi-threaded application development.
  • As the JVM is available for many more platforms, it broadens the reach of Magik, including the potential to run on a class devices never envisioned just a few short years ago.  For example, Java SE compatible runtime environments are available for popular embedded ARM/Intel/PowerPC configurations that could theoretically host this software too.
As compared to other JVM language projects, the Magik integration differs in that it represents a serious commercial entity betting a sizable part of its business on the success of this effort.  Expect to see announcements not only from General Electric, but other organizations as they realize the benefits of utilizing the Java Virtual Machine.

Tuesday Oct 09, 2012

Raspberry Pi and Java SE: A Platform for the Masses

One of the more exciting developments in the embedded systems world has been the announcement and availability of the Raspberry Pi, a very capable computer that is no bigger than a credit card.  At $35 US, initial demand for the device was so significant, that very long back orders quickly ensued. After months of patiently waiting, mine finally arrived. 

Those initial growing pains appear to have been fixed, so availability now should be much more reasonable. At a very high level, here are some of the important specs:

  • Broadcom BCM2835 System on a chip (SoC)
  • ARM1176JZFS, with floating point, running at 700MHz
  • Videocore 4 GPU capable of BluRay quality playback
  • 256Mb RAM
  • 2 USB ports and Ethernet
  • Boots from SD card
  • Linux distributions (e.g. Debian) available

So what's taking place taking place with respect to the Java platform and Raspberry Pi?

  • A Java SE Embedded binary suitable for the Raspberry Pi is available for download (Arm v6/7) here.  Note, this is based on the armel architecture, a variety of Arm designed to support floating point through a compatibility library that operates on more platforms, but can hamper performance.  In order to use this Java SE binary, select the available Debian distribution for your Raspberry Pi.
  • The more recent Raspbian distribution is based on the armhf (hard float) architecture, which provides for more efficient hardware-based floating point operations.  However armhf is not binary compatible with armel.  As of the writing of this blog, Java SE Embedded binaries are not yet publicly available for the armhf-based Raspbian distro, but as mentioned in Henrik Stahl's blog, an armhf release is in the works.
  • As demonstrated at the just-completed JavaOne 2012 San Francisco event, the graphics processing unit inside the Raspberry Pi is very capable indeed, and makes for an excellent candidate for JavaFX.  As such, plans also call for a Pi-optimized version of JavaFX in a future release too.
A thriving community around the Raspberry Pi has developed at light speed, and as evidenced by the packed attendance at Pi-specific sessions at Java One 2012, the interest in Java for this platform is following suit. So stay tuned for more developments...


Monday Aug 13, 2012

Java One 2012 Java SE Embedded Hands On Lab Returns!

After successful runs at Java One 2011 San Francisco and Tokyo, The Java SE Embedded Hands On Lab returns for Java One 2012.  If you're attending the Java One event in San Francisco (Sept 30 - Oct 4), please consider signing up for this session.  As an added incentive, we will be raffling off a couple of the Plug Computer devices that you'll gain experience with during this lab.  Seating is limited to 100 students, so register early.

Here's an overview:

This hands-on lab aims to show that developers already familiar with the Java develop/debug/deploy lifecycle can apply those same skills to develop Java applications, using Java SE Embedded, on embedded devices. The participants in the lab will:

    • Have their own individual embedded device so they can gain valuable hands-on experience
    • Turn their embedded device into a web container, using off-the-shelf software
    • Learn how to deploy embedded Java applications, developed with an IDE, onto their device
    • Learn how embedded Java applications can be remotely debugged from their desktop IDE
    • Learn how to remotely monitor and manage embedded Java applications from their desktop

The course description can be found here:
HOL 7889: Java SE Embedded Development Made Easy

In addition, 2012 marks the first year that we will have a venue specifically tailored for the Java embedded community.  Entitled Java Embedded @ Java One,  this event takes place during the JavaOne/OpenWorld week in San Francisco on October 3-4.  To Quote from the Java Embedded @ Java One URL:

The conference will feature dedicated business-focused content from Oracle discussing how Java Embedded delivers a secure, optimized environment ideal for multiple network-based devices, as well as meaningful industry-focused sessions from peers who are already successfully utilizing Java Embedded.

So if you want to participate in what many consider to be the next big trend in computing -- the internet of things -- come join us 10/3-4 in San Francisco.

Friday Jun 22, 2012

Healthcare Mobile Database Synchronization Demonstration

Like many of you, I learn best by getting my hands dirty.  When confronted with the task of understanding a new set of products and technologies and figuring out how they might apply to a vertical industry like healthcare, I set out to create a demonstration.  The video that follows aims to show how the Oracle embedded software portfolio can be applied to a healthcare application.  The demonstration utilizes among others, Java SE Embedded, Berkeley DB, Apache Tomcat, Oracle 11gR2 and Oracle Database Mobile Server.

Eric Jensen gives a great critique and description of the demo here.  To sum it up, we aim to show how live medical data can be collected on a medical device, stored in a local database, synchronized to a master database and furthermore propagated to a mobile phone (Android) application.  Come take a look!


Monday Mar 19, 2012

Take Two: Comparing JVMs on ARM/Linux

Although the intent of the previous article, entitled Comparing JVMs on ARM/Linux, was to introduce and highlight the availability of the HotSpot server compiler (referred to as c2) for Java SE-Embedded ARM v7,  it seems, based on feedback, that everyone was more interested in the OpenJDK comparisons to Java SE-E.  But there were two main concerns:

  • The fact that the previous article compared Java SE-E 7 against OpenJDK 6 might be construed as an unlevel playing field because version 7 is newer and therefore potentially more optimized.
  • That the generic compiler settings chosen to build the OpenJDK implementations did not put those versions in a particularly favorable light.

With those considerations in mind, we'll institute the following changes to this version of the benchmarking:

  1. In order to help alleviate an additional concern that there is some sort of benchmark bias, we'll use a different suite, called DaCapo.  Funded and supported by many prestigious organizations, DaCapo's aim is to benchmark real world applications.  Further information about DaCapo can be found at http://dacapobench.org.
  2. At the suggestion of Xerxes Ranby, who has been a great help through this entire exercise, a newer Linux distribution will be used to assure that the OpenJDK implementations were built with more optimal compiler settings.  The Linux distribution in this instance is Ubuntu 11.10 Oneiric Ocelot.
  3. Having experienced difficulties getting Ubuntu 11.10 to run on the original D2Plug ARMv7 platform, for these benchmarks, we'll switch to an embedded system that has a supported Ubuntu 11.10 release.  That platform is the Freescale i.MX53 Quick Start Board.  It has an ARMv7 Coretex-A8 processor running at 1GHz with 1GB RAM.
  4. We'll limit comparisons to 4 JVM implementations:
    • Java SE-E 7 Update 2 c1 compiler (default)
    • Java SE-E 6 Update 30 (c1 compiler is the only option)
    • OpenJDK 6 IcedTea6 1.11pre 6b23~pre11-0ubuntu1.11.10.2 CACAO build 1.1.0pre2
    • OpenJDK 6 IcedTea6 1.11pre 6b23~pre11-0ubuntu1.11.10.2 JamVM build-1.6.0-devel

Certain OpenJDK implementations were eliminated from this round of testing for the simple reason that their performance was not competitive.  The Java SE 7u2 c2 compiler was also removed because although quite respectable, it did not perform as well as the c1 compilers.  Recall that c2 works optimally in long-lived situations.  Many of these benchmarks completed in a relatively short period of time.  To get a feel for where c2 shines, take a look at the first chart in this blog.

The first chart that follows includes performance of all benchmark runs on all platforms.  Later on we'll look more at individual tests.  In all runs, smaller means faster.  The DaCapo aficionado may notice that only 10 of the 14 DaCapo tests for this version were executed.  The reason for this is that these 10 tests represent the only ones successfully completed by all 4 JVMs.  Only the Java SE-E 6u30 could successfully run all of the tests.  Both OpenJDK instances not only failed to complete certain tests, but also experienced VM aborts too.

One of the first observations that can be made between Java SE-E 6 and 7 is that, for all intents and purposes, they are on par with regards to performance.  While it is a fact that successive Java SE releases add additional optimizations, it is also true that Java SE 7 introduces additional complexity to the Java platform thus balancing out any potential performance gains at this point.  We are still early into Java SE 7.  We would expect further performance enhancements for Java SE-E 7 in future updates.

In comparing Java SE-E to OpenJDK performance, among both OpenJDK VMs, Cacao results are respectable in 4 of the 10 tests.  The charts that follow show the individual results of those four tests.  Both Java SE-E versions do win every test and outperform Cacao in the range of 9% to 55%.

For the remaining 6 tests, Java SE-E significantly outperforms Cacao in the range of 114% to 311%

So it looks like OpenJDK results are mixed for this round of benchmarks.  In some cases, performance looks to have improved.  But in a majority of instances, OpenJDK still lags behind Java SE-Embedded considerably.

Time to put on my asbestos suit.  Let the flames begin...

Tuesday Feb 14, 2012

Comparing JVMs on ARM/Linux

For quite some time, Java Standard Edition releases have included both client and server bytecode compilers (referred to as c1 and c2 respectively), whereas Java SE-Embedded binaries only contained the client c1 compiler.  The rationale for excluding c2 stems from the fact that (1) eliminating optional components saves space, where in the embedded world, space is at a premium, and (2) embedded platforms were not given serious consideration for handling server-like workloads.  But all that is about to change.  In anticipation of the ARM processor's legitimate entrance into the server market (see Calxeda), Oracle has, with the latest update of Java SE-Embedded (7u2), made the c2 compiler available for ARMv7/Linux platforms, further enhancing performance for a large class of traditional server applications. 

These two compilers go about their business in different ways.  Of the two, c1 is a lighter optimizing compiler, but has faster start up.  It delivers excellent performance and as the default bytecode compiler, works extremely well in almost all situations.  Compared to c1, c2 is the more aggressive optimizer and is suited for long-lived java processes.  Although slower at start up, it can be shown to achieve better performance over time.  As a case in point, take a look at the graph that follows.

One of the most popular Java-based applications, Apache Tomcat, was installed on an ARMv7/Linux device.   The chart shows the relative performance, as defined by mean HTTP request time, of the Tomcat server run with the c1 client compiler (red line) and the c2 server compiler (blue line).  The HTTP request load was generated by an external system on a dedicated network utilizing the ab (Apache Bench) program.  The closer the response time is to zero the better, you can see that for the initial run of 25,000 HTTP requests, the c1 compiler produces faster average response times than c2.  It takes time for the c2 compiler to "warm up", but once the threshold of 50,000 or so requests is met, the c2 compiler performance is superior to c1.  At 250,000 HTTP requests, mean response time for the c2-based Tomcat server instance is 14% faster than its c1 counterpart.

It is important to realize that c2 assumes, and indeed requires more resources (i.e. memory).  Our sample device with 1GB RAM, was more than adequate for these rounds of tests.  Of course your mileage may vary, but if you have the right hardware and the right workload, give c2 a further look.

While discussing these results with a few of my compadres, it was suggested that OpenJDK and some of its variants be included in on this comparison.  The following chart shows mean http request times for 6 different configurations:

  1. Java SE Embedded 7u2 c1 Client Compiler
  2. Java SE Embedded 7u2 c2 Server Compiler
  3. OpenJDK Zero VM (build 20.0-b12, mixed mode) OpenJDK 1.6.0_24-b24 (IcedTea6 1.12pre)
  4. JamVM (build 1.6.0-devel, inline-threaded interpreter with stack-caching) OpenJDK 1.6.0_24-b24 (IcedTea6 1.12pre)
  5. CACAO (build 1.1.0pre2, compiled mode) OpenJDK 1.6.0_24-b24 (IcedTea6 1.12pre)
  6. Interpreter only: OpenJDK Zero VM (build 20.0-b12, interpreted mode) OpenJDK 1.6.0_24-b24 (IcedTea6 1.12pre)

Results remain pretty much unchanged, so only the first 4 runs (25K-100K requests) are shown.  As can be seen, The Java SE-E VMs are on the order of 3-5x faster than their OpenJDK counterparts irrespective of the bytecode compiler chosen.  One additional promising VM called shark was not included in these tests because, although it built from source successfully, it failed to run Apache Tomcat.  In defense of shark, the ARM version may still be in development (i.e. non-stable) mode.

Creating a really fast virtual machine is hard work and takes a lot of time to perfect.  Considering the resources expended by Oracle (and formerly Sun), it is no surprise that the commercial Java SE VMs are excellent performers.  But the extent to which they outperform their OpenJDK counterparts is surprising.  It would be no shock if someone in the know could demonstrate better OpenJDK results.  But herein lies one considerable problem:  it is an exercise in patience and perseverance just to locate and build a proper OpenJDK platform suitable for a particular CPU/Linux configuration.  No offense would be taken if corrections were presented, and a straightforward mechanism to support these OpenJDK builds were provided.

Tuesday Jan 03, 2012

Tomcat Micro Cluster

The term Micro Server has been bandied about recently as a means to provide a certain class of server functionality. As embedded systems continue their inexorable drive towards better performance, and standard hardware/software architectures become ubiquitous, the notion of using low-cost, low-power, small-footprint devices as servers becomes quite realistic.  Just as data center managers have utilized multitudes of affordable rack mount servers to provide scalability, why not duplicate that effort with these off-the-shelf devices?

The video that follows takes the Micro Server to its next logical evolution: The Micro Cluster.  Built from commodity hardware (and by commodity I mean The Home Depot), the cluster board has a rack mount form factor that can house 12 Plug Computers.  As the Java SE HotSpot Virtual Machine is available for the Plug Computer (ArmV5/Linux), we'll utilize Apache Tomcat to demonstrate a Tomcat Micro Cluster.  Over time, as the individual compute nodes increase in performance and capacity, this should become even more compelling.

Monday Oct 24, 2011

Java ONE 2011 Hands on Lab for Java SE Embedded

Now that the dust has settled, sincere thanks go out to my compadres (you know who you are) for helping make The Java One 2011 Java SE Embedded Hands on Lab such a success.  In fact it was so well received, our peers in Asia are already planning on replicating the effort for JavaOne Tokyo in April 2012.  In addition to the Tokyo event,  we hope to provide future opportunities for this venue elsewhere.  In the interim, we'd seriously consider hosting this lab, albeit on a smaller scale (Java One had 105 networked devices and workstations), for interested customers.  To give you a feel for the lab contents, here's a synopsis:

Java One 2011 Hands on Lab 24642: Java SE Embedded Development Made Easy

This Hands-on Lab aims to show that developers already familiar with the Java develop/debug/deploy lifecycle can apply those same skills to develop Java applications, using Java SE Embedded, on embedded devices.  Each participant in the lab will:

  • Have their own individual embedded device to gain valuable hands on experience
  • Turn their embedded device into a Java Servlet container
  • Learn how to deploy embedded Java applications, developed with the NetBeans IDE, onto their device
  • Learn how embedded Java applications can be remotely debugged from their desktop NetBeans IDE
  • Learn how to remotely monitor and manage embedded Java applications from their desktop
If the logistics for setting up a lab prove to be a bit too much, as an alternative, we've given quite a few live presentations/demonstrations with similar flair.  So please, by all means, contact me at james.connors@oracle.com, if you're interested in learning more.  For those of you who run developer user groups, most notably Java User Groups, and are looking for a speaker at your next meeting, please consider us.  We will not disappoint.


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 http://rxtx.qbang.org/wiki/index.php/Download 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 configure.in file in the source directory and look for the following:

    case $JAVA_VERSION in
    1.2*|1.3*|1.4*|1.5*)

and change the second line to:

    1.2*|1.3*|1.4*|1.5*|1.6*)

Upon modification, the autogen.sh 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.

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

    case $JAVA_VERSION in
    1.2*|1.3*|1.4*|1.5*)

and change the second line to:

    1.2*|1.3*|1.4*|1.5*|1.6*)

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 librxtxSerial.so, 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 librxtxSerial-2.1-7.so $JAVA_HOME/lib/arm
    # cd $JAVA_HOME/lib/arm
    # ln -s librxtxSerial-2.1-7.so librxtxSerial.so

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  librxtxSerial-2.1-7.so 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

Introduction

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

The Application

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

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

Comparing the Size of the Source Code

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

JavaFX Script source file

Number of Lines

Number of Character

JavaFX 2.0 Java source file

Number of Lines

Number of Characters




ArrowKey.java

6

72

Board.fx

221

6831

Board.java

205

6508

BoardNode.fx

446

16054

BoardNode.java

723

29356

ChooseNumberNode.fx

168

5267

ChooseNumberNode.java

302

10235

CloseButtonNode.fx

115

3408

CloseButton.java

99

2883




ParentWithKeyTraversal.java

111

3276




FunctionPtr.java

6

80




Globals.java

20

554

Grouping.fx

8

140




HowToPlayNode.fx

121

3632

HowToPlayNode.java

136

4849

IconButtonNode.fx

196

5748

IconButtonNode.java

183

5865

Main.fx

98

3466

Main.java

64

2118

SliderNode.fx

288

10349

SliderNode.java

350

13048

Space.fx

78

1696

Space.java

106

2095

SpaceNode.fx

227

6703

SpaceNode.java

220

6861

TraversalHelper.fx

111

3095




Total

2,077

79,127


2531

87,800

A few notes about this table are in order:

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

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

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

RAM consumption

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

What About Binding?

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

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

JavaFX Script source file

Number of Binds

JavaFX Next Java source file

Number of “Binds”



ArrowKey.java

0

Board.fx

1

Board.java

0

BoardNode.fx

7

BoardNode.java

0

ChooseNumberNode.fx

11

ChooseNumberNode.java

0

CloseButtonNode.fx

6

CloseButton.java

0



CustomNodeWithKeyTraversal.java

0



FunctionPtr.java

0



Globals.java

0

Grouping.fx

0



HowToPlayNode.fx

7

HowToPlayNode.java

0

IconButtonNode.fx

9

IconButtonNode.java

0

Main.fx

1

Main.java

0

Main_Mobile.fx

1



SliderNode.fx

6

SliderNode.java

1

Space.fx

0

Space.java

0

SpaceNode.fx

9

SpaceNode.java

1

TraversalHelper.fx

0



Total

58


2

Conclusions

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

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!


Thursday May 26, 2011

The Shackles are Off

Today marks an important milestone for JavaFX 2.0.  Prior to this date, only a select few partners had early access privilege to the technology, and for good reason.  During that early access period, the API was in a very fluid state, and from personal experience I can tell you that changes to the JavaFX 2.0 API were done almost on a build-by-build basis.  The announcement of a public beta not only makes the software available worldwide, but also signals that the JavaFX 2.0 API is on much more solid footing.

So check out the javafx.com website for the latest JavaFX 2.0 information.   Three software downloads are now available:

  1. JavaFX 2.0 Beta SDK - the JavaFX functionality needed to develop directly via the command line or with other tools
  2. JavaFX 2.0 Beta Runtime - the runtime environment required for running JavaFX 2.0 applications 
  3. JavaFX 2.0 Beta Plugin for NetBeans IDE 7.0 -  for building, previewing, and debugging JavaFX applications in NetBeans 7.

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.

About

Jim Connors

Search

Categories
Archives
« March 2015
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
    
       
Today