Welcome to the last JavaFX links of the week for this year! Obviously with the festive season in full swing this week is a relatively quiet week, but nonetheless I have some interesting links for you to read. Enjoy, and have a good new years and start to 2013! Catch you in a weeks time! 🙂

Stephen Chin has announced his plans to go on another night hacking tour, this time taking in the Nordic countries between January 25 and February 7.

I was given a (virtual) clip around the head by Ed Thompson for his issues when dealing with the JavaFX ComboBox control. Fortunately most issues are on their way towards being resolved, and as always I’d love to work with people feeling pain in any UI control to develop improvements and / or review patches based on the OpenJFX source code.

Hendrik Ebbers has started playing with JavaFX on Raspberry Pi. He has been investigating using DataFX and GridFX on it, and has posted some videos to show progress.

Richard Bair posted some performance numbers for Java on the Raspberry Pi, showing that it is possible to get really good performance out of such a cheap and low-powered device. He also has a few useful tips for how to get JavaFX applications working on it.

Robert Savage has posted another tutorial on setting up the Raspberry Pi to use JDK 8, with greater detail on how to SSH into it (which is useful for those of you not wanting to hook up another keyboard, mouse and screen).

JavaSE is a HotSpot based VM, so it is really quite zippy. I did some timing calculations on my PI this morning based on the prime number test provided in this Raspberry PI Java forum posting. Yes, there is a new Java category on the Raspberry PI forums, do visit and leave your experiences there :-). Anyway, I ran both Java and GCC version 4.6.3 with -O2 performance optimization enabled.

Test

Real

User

Sys

JavaSE 8 (build 1.8.0-ea-b36e)

0m7.830s

0m4.970s

0m2.840s

GCC 4.6.3 (Debian 4.6.3-12+rpi1)

0m7.716s

0m4.990s

0m2.700s

GCC 4.6.3 (Debian 4.6.3-12+rpi1) -O2

0m6.361s

0m3.940s

0m2.400s

I find the results really impressive, because basically the difference seen between Java and native is just due to the startup costs. Which means that Java is a really great choice for developing applications that will run on the Raspberry PI. Java also represents (to my knowledge) the first VM stack to optimize for hard float on ARM v6.

I couldn’t help myself though, I cranked up the test to find all prime numbers below 50,000 to see if the startup costs in fact are the difference between the JVM and native code. Below are the results. As you can see, HotSpot is faster than native code!

Test

Real

User

Sys

JavaSE 8 (build 1.8.0-ea-b36e)

1m37.808s

1m25.570s

0m12.000s

GCC 4.6.3 (Debian 4.6.3-12+rpi1)

2m18.875s

2m7.390s

0m11.1300s

GCC 4.6.3 (Debian 4.6.3-12+rpi1) -O2

1m42.166s

1m31.206s

0m10.580s

I wrote a quick JavaFX application this morning and tried it out. A couple things to make sure you note!

jfxrt.jar is not on the classpath by default (yet). So be sure to include it!

-Djavafx.platform=eglfb must be specified. If not, it won’t run.

Ahem. There appears to be no way to kill an FX app, unless you can SSH into your box or switch to another terminal. Or have your app make sure it has an exit button. But then, when playing BrickBreaker, who’d ever want to stop?

None of the flags used in javaFX on the command line are “public API” and may go away in the future, but this particular flag is likely to be around for a while. It lets you choose which version of glass to run with. On Raspberry PI, right now, the only option is eglfb (which makes you wonder why we require you to specify it on the command line. There are some questions that we just shouldn’t ask ;-)). Basically EGLFB runs OpenGL on the frame buffer directly, meaning that it wants to own the entire screen. This is great for Kiosks and media centers and such, but not so good for normal X11 usage. Hopefully the X11 usage shows up sometime soon, but in the meantime, JavaFX will own the display.

Google has been kind enough to pull together a collection of great free fonts at http://www.google.com/webfonts. For ages I have wanted a easy way to use these in my JavaFX applications. This week I added basic support to JavaFX for CSS @font-face support (see RT-10343). It should be going into JDK 8-b69 which will be available later this week.

2012 is rapidly running out, but fortunately the number of links (and the quality) continues to rise. 2013 looks like it might be a very good year for desktop Java at this rate! Keep up the great work folks:-)

To aid people working on the FX Game project (which is currently focused on building a Tower Defense game), Daniel Zwolenski has started up a Google group mailing list. If you’re interested in taking part, head over there, sign up and introduce yourself!

Bruno Borges has started a new project called WebFX, which intends to “investigate the capabilities of using JavaFX (FXML + JS + CSS) to build rich web pages, instead of using HTML. With the new Javascript engine, Nashorn, the performance of a JavaFX page in FXML and the controllers in JS will be much higher than it is today. Idea is to build an FX browser, a security layer, a navigation scheme where one FXML can tell the browser to go to another FXML and a protocol for server-side communication.”

Filipe Portes has posted to GitHub code for a new project of his called ModuleFX, which “embeds the JavaFX Runtime inside an OSGI bundle, allowing you to create modular JavaFX apps with all the power of OSGI framework, getting the best of Java Rich Client and Modularization worlds together.”