JavaSE Embedded 8 + JavaFX for Raspberry PI (hard float)

[rbair]

Hey,

http://jdk8.java.net/fxarmpreview/javaf ... eview.html
http://javafx.steveonjava.com/javafx-on ... asy-steps/

You can now go grab JavaSE Embedded 8 developer preview (including JIT, hotspot) for Raspberry PI, hard float, and JavaFX. I did a build and install this morning. The main thing to be aware of for the JavaFX stuff is that right now we have only released the EGLFB version of the graphics stack, which means it will take over control of the frame buffer, which basically means that it is useful for Kiosk / media center types of scenarios but not for X11 usage (our X11 port to PI doesn't yet have hardware acceleration and isn't ready for release).

Kick the tires an let us know what you think!

[henrik]

Two comments:

This is an early access of JDK 8, not Java SE Embedded. The former is our generic Java development kit (with runtime). The latter is a commercial product optimized for low memory footprint.

Swing/AWT is not included in JDK 8 for Linux/ARM at this time, and we don't know if it will be there in JDK 8 GA or not yet. Our recommended UI framework is JavaFX.

Henrik (Java Platform Group @ Oracle)

[rbair]

Two comments:

This is an early access of JDK 8, not Java SE Embedded. The former is our generic Java development kit (with runtime). The latter is a commercial product optimized for low memory footprint.

Henrik (Java Platform Group @ Oracle)

Thanks for the clarification!

[chriswhocodes]

Awesome!

Shame I saw this late tonight so will have to wait until tomorrow to try it out.

I've built a wearable Pi with video glasses so full screen FB is better for me

These pages look useful for anyone trying it out tonight:
http://javafx.steveonjava.com/javafx-on ... asy-steps/
http://fxexperience.com/2012/12/javafx-on-raspberry-pi/
http://jdk8.java.net/fxarmpreview/javaf ... eview.html

[JetForMe]

I'm excited about hard-float support in Java. I do a lot of webapp development using J2EE. Is it reasonable to try to run this on RaspberryPi?

[savageautomate]

I have also posted a complete set of instructions for:
Installing Oracle Java SE 8 (with JavaFX) Developer Preview for ARM

See this post:
http://www.raspberrypi.org/phpBB3/viewt ... 75#p237175

[henrik]

I'm excited about hard-float support in Java. I do a lot of webapp development using J2EE. Is it reasonable to try to run this on RaspberryPi?

GlassFish runs really well on Oracle JDK 7 on the Pi. There may be glitches getting it to run on JDK 8 EA, let us know if you run into any issues.

Henrik

[plugwash]

This is an early access of JDK 8, not Java SE Embedded. The former is our generic Java development kit (with runtime). The latter is a commercial product optimized for low memory footprint.

Does this include a hotspot JIT port for armv6 hardfloat? if so will that JIT be making it's way into openjdk.

Swing/AWT is not included in JDK 8 for Linux/ARM at this time, and we don't know if it will be there in JDK 8 GA or not yet. Our recommended UI framework is JavaFX.

Any particular reason for not including it? does it fail to build? are you worried about performance?

[henrik]

This is an early access of JDK 8, not Java SE Embedded. The former is our generic Java development kit (with runtime). The latter is a commercial product optimized for low memory footprint.

>Does this include a hotspot JIT port for armv6 hardfloat? if so will that JIT >be making it's way into openjdk.

Yes, client and server JIT to armv6 hardfloat. No, we are not planning on open sourcing our ARM port. We fund Java development by selling Java for embedded systems, and if we were to open source our port we would lose a lot of revenue which would mean less money to invest in Java. For now you'll have to settle for a free-as-in-beer implementation for the Pi (for general-purpose use, not that if you build it into a commercial embedded device you have to get a commercial license which costs on the order of a dollar per unit).

Swing/AWT is not included in JDK 8 for Linux/ARM at this time, and we don't know if it will be there in JDK 8 GA or not yet. Our recommended UI framework is JavaFX.

Any particular reason for not including it? does it fail to build? are you worried about performance?

The reason we can maintain a Raspberry Pi port for "free" is because it's based on our commercial embedded port. For JDK 8 we are moving to JavaFX as the recommended UI for embedded, so we currently don't have Swing/AWT in plan for ARM.

JavaFX is a much better fit since it's fully HW accelerated which is really needed on low power devices. Note that JavaFX will be completely open source through the OpenJFX project (including our ARM port). Part of it is open today, we expect to have everything out in a few more months. Would be great to have Pi community pitch in here to add things like X11 support (we are currently only doing framebuffer which is all we need for embeddef systems).

Henrik

[chriswhocodes]

Hi,

Having a couple of problems with the JavaFX samples.

Stopwatch:
Starts up and shows a frozen stopwatch with a mouse cursor but can't move the cursor with mouse and keys don't have any effect.

Redirected process output to a file and it shows

Code: Select all

ES2Pipeline: OpenGL ES 2.0 embedded device detected
glGetError 0x500

Java process started with

Code: Select all

./jdk1.8.0/bin/java -Djavafx.platform=eglfb -cp ./jdk1.8.0/jre/lib/jfxrt.jar:./javafx-samples-8.0.0-ea/StopWatch.jar stopwatch.MainScreen >log 2>&1

Same error and frozen screen on Bouncing Balls started with

Code: Select all

./jdk1.8.0/bin/java -Djavafx.platform=eglfb -cp ./jdk1.8.0/jre/lib/jfxrt.jar:./javafx-samples-8.0.0-ea/BouncingBalls.jar balls.Main >log 2>&1

[rbair]

Hi Chris,

It sounds like a problem with mouse / keyboard input. I've forwarded the post to the engineers, they should get back to you soon. We had a similar bug on Mark Reinhold's PI (which, incidentally, led to the crash during the keynote). What we found was his PI had several different mouse devices. We changed some symlinks to get it to be the one that our PI port seemed to be expecting (I don't remember the device ID off the top of my head).

[jackokring]

I use the non HDMI video. The settings say the full HD framebuffer is needed. I'll test when 640 by 480 works. Don't need X, in fact I'd be more a fan of moving the X server to JavaFX.

[chriswhocodes]

Hi Chris,

It sounds like a problem with mouse / keyboard input. I've forwarded the post to the engineers, they should get back to you soon. We had a similar bug on Mark Reinhold's PI (which, incidentally, led to the crash during the keynote). What we found was his PI had several different mouse devices. We changed some symlinks to get it to be the one that our PI port seemed to be expecting (I don't remember the device ID off the top of my head).

Hi, yes that was the problem. I was using the "Rii 2.4GHz Wireless Mini PC Keyboard Touchpad V2" with an integrated mouse pad. The demos work fine with a Microsoft USB mouse.

Thanks

[xranby]

This is an early access of JDK 8, not Java SE Embedded. The former is our generic Java development kit (with runtime). The latter is a commercial product optimized for low memory footprint.

>Does this include a hotspot JIT port for armv6 hardfloat? if so will that JIT >be making it's way into openjdk.

Yes, client and server JIT to armv6 hardfloat. No, we are not planning on open sourcing our ARM port. We fund Java development by selling Java for embedded systems, and if we were to open source our port we would lose a lot of revenue which would mean less money to invest in Java. For now you'll have to settle for a free-as-in-beer implementation for the Pi (for general-purpose use, not that if you build it into a commercial embedded device you have to get a commercial license which costs on the order of a dollar per unit).

Swing/AWT is not included in JDK 8 for Linux/ARM at this time, and we don't know if it will be there in JDK 8 GA or not yet. Our recommended UI framework is JavaFX.

Any particular reason for not including it? does it fail to build? are you worried about performance?

The reason we can maintain a Raspberry Pi port for "free" is because it's based on our commercial embedded port. For JDK 8 we are moving to JavaFX as the recommended UI for embedded, so we currently don't have Swing/AWT in plan for ARM.

JavaFX is a much better fit since it's fully HW accelerated which is really needed on low power devices. Note that JavaFX will be completely open source through the OpenJFX project (including our ARM port). Part of it is open today, we expect to have everything out in a few more months. Would be great to have Pi community pitch in here to add things like X11 support (we are currently only doing framebuffer which is all we need for embeddef systems).

Henrik

There is not a technical barrier to get X11 supported and Swing/AWT working on ARM.
The JNI interface, with "Classpath" exception, clearly separate the JVM and the runtime environment classes.
If you use the Client Hotspot (jre/lib/arm/client/libjvm.so) from the JavaFX 8 preview in combination with the Rasbian compiled OpenJDK 7 Runtime environment classes and java launchers (/usr/lib/jvm/java-7-openjdk-armhf) you will get the following setup and benefits:
* Hotspot Client JIT (from the JavaFX 8 preview)
* Swing/AWT support (using the OpenJDK classes from the icedtea-7-jre package)
* pulse-audio support (IcedTea pulse-java from the openjdk-7-jre and openjdk-7-jre-headless package)
* web-browser applet support using icedtea-web (from the icedtea-7-plugin package)
* a JNLP javaws launcher using icedtea-web (from the icedtea-7-plugin package)
* armhf JNI autodetection by the OpenJDK java launchers (the OpenJDK java launchers adds the armhf specific system library path into java.library.path). By including the /usr/lib/arm-linux-gnueabihf path into java.library.path allows java libraries such as the Pi4J GPIO library and the JogAmp gluegen-rt JOGL/JOAL to correctly detect that it is running on a armhf linux system and then load the armhf JNI implementation instead of the armel JNI implementation.
* Image processing and printing support inside JavaEE server applications, such as glassfish and tomcat, by using the headfull OpenJDK classes.

[danielblaukopf]

Hi Chris,

It sounds like a problem with mouse / keyboard input. I've forwarded the post to the engineers, they should get back to you soon. We had a similar bug on Mark Reinhold's PI (which, incidentally, led to the crash during the keynote). What we found was his PI had several different mouse devices. We changed some symlinks to get it to be the one that our PI port seemed to be expecting (I don't remember the device ID off the top of my head).

Hi, yes that was the problem. I was using the "Rii 2.4GHz Wireless Mini PC Keyboard Touchpad V2" with an integrated mouse pad. The demos work fine with a Microsoft USB mouse.

Thanks

Yes, the preview only supports a single pointer device and single key device. You get the devices with the lowest IDs in /dev/input/event* - usually this means the one that Linux found first.

This is being fixed, along with various other input glitches.

Daniel

[plugwash]

There is not a technical barrier to get X11 supported and Swing/AWT working on ARM.
The JNI interface, with "Classpath" exception, clearly separate the JVM and the runtime environment classes.
If you use the Client Hotspot (jre/lib/arm/client/libjvm.so) from the JavaFX 8 preview in combination with the Rasbian compiled OpenJDK 7 Runtime environment classes and java launchers (/usr/lib/jvm/java-7-openjdk-armhf) you will get the following setup and benefits:

For those of us who don't live and breathe java can you provide any hints on the neatest way of setting that up?
Also is it something you have actually tested or just something you think should work?

[xranby]

There is not a technical barrier to get X11 supported and Swing/AWT working on ARM.
The JNI interface, with "Classpath" exception, clearly separate the JVM and the runtime environment classes.
If you use the Client Hotspot (jre/lib/arm/client/libjvm.so) from the JavaFX 8 preview in combination with the Rasbian compiled OpenJDK 7 Runtime environment classes and java launchers (/usr/lib/jvm/java-7-openjdk-armhf) you will get the following setup and benefits:

For those of us who don't live and breathe java can you provide any hints on the neatest way of setting that up?

IANAL:

Code: Select all

# Install openjdk-7 and the icedtea-web browser plugin
sudo apt-get install openjdk-7-jre icedtea-7-plugin
# Extract the Oracle Client Hotspot JVM from the JavaFX 8 preview
tar --extract --verbose --file=jdk-8-ea-b36e-linux-arm-hflt-29_nov_2012.tar.gz jdk1.8.0/jre/lib/arm/client
# Place the client hotspot dir containing the libjvm.so inside the OpenJDK 7 jre/lib/arm folder
sudo mv jdk1.8.0/jre/lib/arm/client /usr/lib/jvm/java-7-openjdk-armhf/jre/lib/arm/oracle
# Configure the OpenJDK Runtime to use the Oracle client Hotspot JVM dir
# This sed command places -oracle KNOWN at the first line of jvm-armhf.cfg
sudo sed -i -e "1i\\-oracle KNOWN" /etc/java-7-openjdk/jvm-armhf.cfg

Also is it something you have actually tested or just something you think should work?

java -version
java version "1.7.0_07" <--- This is the OpenJDK 7 Update version
OpenJDK Runtime Environment (IcedTea7 2.3.2) (7u7-2.3.2a-1+rpi1) <--- This is the OpenJDK 7 Runtime version
Java HotSpot(TM) Client VM (build 25.0-b04, mixed mode) <--- This is the Oracle Client Hotspot JVM version

[freedomotic]

I have also posted a complete set of instructions for:
Installing Oracle Java SE 8 (with JavaFX) Developer Preview for ARM

See this post:
http://www.raspberrypi.org/phpBB3/viewt ... 75#p237175

Hi Robert
thanks for your tutorial. Following it i installed oracle jdk 1.8 on raspbian and it works.
I'm testing our domotic software and it works but I'd like to say if there are some tips/configuration parameters for the jvm to have better performances in particular with a gui in java.
Thanks
Mauro

[xranby]

I'm testing our domotic software and it works but I'd like to say if there are some tips/configuration parameters for the jvm to have better performances in particular with a gui in java.
Thanks
Mauro

My understanding is that your domotic software use the following GUI software stack:
"Desktop" OpenGL mesa (software CPU emulated) <-- Old Sun JOGL 1.1.1a <-- Old Sun Java3D <-- SweetHome3D <-- domotic
This will be slow because the Old Sun Java3D and JOGL 1.1.1a can only use desktop OpenGL.

Ideally you want to rearrange the foundation of this stack to use:
"Mobile/Embedded" OpenGL ES using the Broadcom libraries <-- New JogAmp JOGL 2 <-- New Java 3D internally using GL2ES2 or GL2ES1 profile <-- SweetHome3D <-- domotic

I have documented that the key people behind the Sun JOGL 1 and Sun Java3D have left and these two Sun software stacks are currently unmaintained since 2009.
The JogAmp community is maintaining a new version of JOGL 2 and Java3D that uses JogAmp JOGL 2: http://labb.zafena.se/?p=656

It is not possible to accelerate your GUI stack on the Raspberry Pi unless the following blocking issues gets fixed:
First we need to update the new Java3D that uses JogAmp JOGL 2 to use an OpenGL ES compatible profile: https://github.com/hharrison/java3d-core/issues/8
Then we need to add Swing and AWT interoperability for the Broadcom VC IV driver in JogAmp JOGL 2 : https://jogamp.org/bugzilla/show_bug.cgi?id=626

[henrik]

I'm testing our domotic software and it works but I'd like to say if there are some tips/configuration parameters for the jvm to have better performances in particular with a gui in java.
Thanks
Mauro

Ideally you want to rearrange the foundation of this stack to use:
"Mobile/Embedded" OpenGL ES using the Broadcom libraries <-- New JogAmp JOGL 2 <-- New Java 3D internally using GL2ES2 or GL2ES1 profile <-- SweetHome3D <-- domotic


Or (depending on what you want to do) use JavaFX. It doesn't have 3D yet as far as I remember but it does use the HW accelerated OpenGL ES.

Henrik

[kermitas]

Does anybody run something non-javafx like Jetty, Tomcat, Glassfish or other servers?

How it works? Do you feel that it run better/faster?

Thanks:)

[henrik]

Does anybody run something non-javafx like Jetty, Tomcat, Glassfish or other servers?

How it works? Do you feel that it run better/faster?

Thanks:)

I gave my Raspberry Pi to one of our JVM devs so I can't test but the hardfloat JVM should be 10-20% or so faster on anything that involves system calls (graphics, I/O, etc). You may not see this on I/O microbenchmarks since - if I understand correctly - the RPi has a hardware bottleneck with ethernet. Also, you will not see any benefit on a pure CPU benchmark since even the softfloat JVM uses a hardfloat calling convention for JIT compiled code.

Henrik

[kermitas]

I gave my Raspberry Pi to one of our JVM devs so I can't test but the hardfloat JVM should be 10-20% or so faster on anything that involves system calls (graphics, I/O, etc). You may not see this on I/O microbenchmarks since - if I understand correctly - the RPi has a hardware bottleneck with ethernet. Also, you will not see any benefit on a pure CPU benchmark since even the softfloat JVM uses a hardfloat calling convention for JIT compiled code.
Henrik

Thank you Henrik .

[mouseclicker]

Kermitas, I installed the JVM and on latest Raspbian Wheezy and run Tomcat 7. Installed in a couple of minutes and worked like a charm System is under 100% CPU for minutes then, but then response times are good. Cool stuff!

[kermitas]

Kermitas, I installed the JVM and on latest Raspbian Wheezy and run Tomcat 7. Installed in a couple of minutes and worked like a charm System is under 100% CPU for minutes then, but then response times are good. Cool stuff!

Great! Thank you:)
I think JDK8 for ARM hard FP is very good direction!