Raspbian comes with Oracle's Java 8 for the ARM which has the nice JavaFX API using OpenGL-ES.
It's java version "1.8.0".

Also Oracle's update version "1.8.0_06" (8u6) from last year includes JavaFX. Its documentation is on Oracle's website, mentioning JavaFX. (I can't find the JDK binary 8u6 there anymore, just here).

However, with Oracle's most recent Java for the ARM update version "1.8.0_33" (8u33), I can't use the FX API anymore. My older FX programs as well as the JDK's FX demos won't run on the Pi anymore with this 8u33 version.

Is this a bug, or a feature ?

P.S. Yes, the PC's current Java JDK version is "1.8.0_31" (8u31) where all FX stuff runs fine.

Thanks for the link:"Starting with JDK 8u33, JavaFX Embedded is removed from the ARM bundle and is not supported."

This is really bad news. Because the JavaFX API using OpenGL-ES was the main argument making Java attractive aka fast enough on the Pi, using it's GPU for graphics.

Do we know if the Pi Foundation will stay with Java 8u0 or 8u6 (hopefully) for future Raspbian relases, meaning including JavaFX ?
If it used the newer Java 8u33+ versions, older Java software using FX would be broken on the Pi...

Note that setting java.ext.dirs overrides the location of the JRE extension directory, and so any other jars present in the extension directory of your JRE will not be seen.

As an alternative to java.ext.dirs, you can copy the build result on top of a copy of your JRE installation
JAVA_HOME=/opt/jdk1.8.0 # replace with your installation path
# remove some older JFX bits so they don't collide
rm -f $JAVA_HOME/jre/lib/ext/jfx*jar $JAVA_HOME/jre/lib/arm/libjavafx_font_t2k.so
# and then overlay the built bits
cp -r build/armv6hf-sdk/rt/lib $JAVA_HOME/jre/

Note that JavaFX on ARM assumes that it is running as root so that it may open the framebuffer and read directly from udev. It is certainly possible to set up system permissions so that running as root is not required.

Diegobernardes, since the Raspberry Pi is a more fixed device compared to an always-changing PC/OS, you could just continue to use the current Oracle Java 8 which is shipped with the current Raspbian.

Also Oracle's newer Java 8u6 update is usable with JavaFX on the Pi.

In case you want to deploy your JavaFX application to Pi users or with a Pi, you could always bundle your needed Java JDK (or its smaller JRE) with your application. This is used often done on PCs, so that nothing changes and your Java app runs fine.

For an JRE example just unpack jdk-8u6-linux-arm-vfp-hflt.tar.gz and copy the jdk1.8.0_6 's jre-folder next to your JAR file, and then use a small shell-script to start your Java app from there, skipping the OS'es installed Java version.

Fidelius wrote:Diegobernardes, since the Raspberry Pi is a more fixed device compared to an always-changing PC/OS, you could just continue to use the current Oracle Java 8 which is shipped with the current Raspbian.

Also Oracle's newer Java 8u6 update is usable with JavaFX on the Pi.

In case you want to deploy your JavaFX application to Pi users or with a Pi, you could always bundle your needed Java JDK (or its smaller JRE) with your application. This is used often done on PCs, so that nothing changes and your Java app runs fine.

For an JRE example just unpack jdk-8u6-linux-arm-vfp-hflt.tar.gz and copy the jdk1.8.0_6 's jre-folder next to your JAR file, and then use a small shell-script to start your Java app from there, skipping the OS'es installed Java version.

Indeed this can be done.
But in my opinion for commercial or new projects is better find a new alternative than using one that already require hacks and tricks to get runing, don't?
Well, i don't know, this new is very recent, let's wait and see what gonna happen..

Normally a PI application (including the Java 8 and 8u6 application) which runs on the current Raspian, should continue to work also in the future. The PI Foundation normally is eager not to break things. (Gnome's Mahjongg from the PI repository is the exception, it broke some Raspbian versions ago.)

Also, on the PC it's common when you deploy a Java app, to include with your app a local Java Runtime Environment (JRE) which the actual app has been developed and tested for. This is safer since you never know what a customer's system has or hasn't installed.

I would do the same on the PI. It's not yet a hack.
Cross-compiling the OpenJFX and poking the result into the PI's JDK is a hack, however. :-)

So, I agree with you that the whole FX kicking in newer ARM Javas is a bad move and results in very unnecessary hassle. It undermines Java 8's FX API and the run-everywhere-philosophy, which Oracle also broke with Java 8's FX media codec API when run on the very wide-spread Ubuntu 14 LTS Linux.

Well, i don't know, this new is very recent, let's wait and see what gonna happen..

Apologies for the terse release note regarding this change to the Oracle JDK for ARM and Oracle Java SE Embedded products. Clearly this change should have come with more context.

Starting with Oracle JDK for ARM 8u33 and Oracle Java SE Embedded 8u33, JavaFX Embedded, a port of JavaFX 8 which was only available on Linux/ARM platforms, is not supported, and has been removed from these downloads.

The complete source code for JavaFX Embedded has been contributed to the OpenJFX open source project in the OpenJDK community under the GPL v2 with Classpath exception license. JavaFX development has been done in the OpenJDK open source community for some time now, enabling JavaFX developers to contribute back their changes to the source code, and produce their own OpenJFX binaries for their target platforms under their own responsibility.

JavaFX continues to be provided as a fully supported part of the Oracle JDK 8 product on x86 platforms (Windows, Linux, Mac). Developers looking for alternatives to JavaFX Embedded could explore and contribute to the OpenJFX project in OpenJDK, or alternative UI frameworks like Swing or AWT.

Out of interest, and I asked the question already in the other Java on Pi2 thread:

Would a Java VM compiled against the Pi2 and its ARM7-Quadcore Cortex-A7 also bring some advantages compared to Raspbian's current Oracle Java8 which is optimised but compiled against ARM6/7 (if it means it uses ARM6 instructions only) ?

(I mean looking at a single core only. Obviously four cores help Java generally.)

Current status is that the latest Raspbian version comes pre-installed with Oracle's Java 8 (internal version 1.8.0 i.e. 8u0) so still has got the JavaFX API included.

Just if you manually download from Oracle the most recent ARM's Java 8 (internal version 1.8.0_33 i.e. 8u33) it lacks the JavaFX API, however. This is totally lame, but well, I don't think it bothers many on the Pi yet, since most (Java) people will just use Raspbian's pre-installed Java (which still includes the JavaFX API).

1) For non-sudo users on the Pi, in order to allow JavaFX in Raspbian's Oracle Java 8u0 or 8u6 to access the Pi's dev/vchiq and /dev/input devices, we just added the user to the Linux group "video" and "input", and everything worked fine.
However with your OpenJFX added to Oracle Java 8u33 (the one missing FX) there seems to be another group, which I don't know yet. With sudo users it works, but with non-sudo users I'm getting these errors:

Udev: Failed to write to /sys/class/input/mice/uevent
Check that you have permission to access input devices
Udev: Failed to write to /sys/class/input/event0/uevent
Check that you have permission to access input devices
Udev: Failed to write to /sys/class/input/event1/uevent
Check that you have permission to access input devices
Udev: Failed to write to /sys/class/input/event2/uevent
Check that you have permission to access input devices
Udev: Failed to write to /sys/class/input/input0/uevent
Check that you have permission to access input devices
Udev: Failed to write to /sys/class/input/input1/uevent
Check that you have permission to access input devices
Udev: Failed to write to /sys/class/input/input2/uevent
Check that you have permission to access input devices
Udev: Failed to write to /sys/class/input/mouse0/uevent
Check that you have permission to access input devices

2) The FX's media package containting for example the new FX sound system has always been missing in Oracle's ARM Java <= 8u6. Which was a pity, because the new javafx.scene.media.AudioClip for example works much more robust than the older javax.sound.sampled.Clip (for example on x86 Linux).
I hoped the OpenJFX would bring this missing media package also to our Pi, but unfortunately it's not there in your compilation. Is there any chance it could come with some future versions?

Perhaps there are some .so binaries that are required as well. Oracle did appear to commit to releasing all of the ARM code as open source in their JavaFX on ARM announcement so hopefully it will appear.

Thanks Chris, for your efforts and postings on the OpenJFX mailing list.

It's a sad situation Oracle has put us in. Judging from the Oracle guys' postings on the mailing list, it means that Java 8u0 and 8u6 always only partly supported FX on ARM machines (see missing media package), and Oracle officially drops FX entirely on the ARM machines starting with Java 8u33.

So a complete Java8 including FX runs on desktop machines only -- but not completely on Ubuntu Linux 14 LTS, where the JavaFX's media package can't do video and audio codecs. And well, many use their Pi2 on the desktop, too. So the complete Java8 including FX does basically run on Windos only. But what do we need it for, then?

The removing of FX in ARM Java is one strange decision when we look at the constantly decreasing numbers of sold desktop PCs and the explosion of numbers of ARM devices including the Pi (~5 millions) which blurs the lines between desktop and "embedded" devices completely. Is the Pi2 not yet available in overseas?

So, practically we could stick with Java 8u0 or 8u6 on the Pi and have at least the bigger parts of JavaFX, until some fat bugs or security holes force us to upgrade. Or wait until some smart people like you and others have all the means to compile a full OpenJFX to the Arm machines.

Confusing. I really liked FX when it was bundled with Java8. But now I say: Bad times for Java friends.

Last edited by Fidelius on Wed Mar 18, 2015 9:07 am, edited 1 time in total.

I'll let you know if I can make any progress getting the media stuff to compile for armv6hf.

Cheers,

Chris

Due to how the Java binary license is written may prevent use of a "Frankenstein" ARM JDK using 8u33 + OpenJFX nightly + media binaries from older Oracle JDKs
OpenJFX adds classes under the com.sun namespace something paragraph F of the binary license of the Oracle JDK prevents you to do.

http://www.oracle.com/technetwork/java/ ... index.html
"F. JAVA TECHNOLOGY RESTRICTIONS. You may not create, modify, or change the behavior of, or authorize your licensees to create, modify, or change the behavior of, classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun", “oracle” or similar convention as specified by Oracle in any naming convention designation."

Thus as i see it, you can only use OpenJFX in combination with OpenJDK where the GPLv2+classpath exception license allows you to add classes under the "java", "javax", "sun", “oracle” namespaces without the above mentioned restriction.

If someone fork OpenJFX and patches it to stop using the com.sun.* "java", "javax", "sun", “oracle” namespaces then it will license compatible with Oracles binary JDK release.

Xerxes Rånby@xranbyI once had two, then I gave one away. Now both are in use every day!
twitter.com/xranby