Are a Java version for RaspberryPi?
Thanks
-
- Posts: 405
- Joined: Sun Nov 20, 2011 11:37 am
Re: Java
If you are using Arch, try:
It's in the repo.
Arch Arm Packages
Code: Select all
pacman -S jdk7-openjdk
Arch Arm Packages
-
- Posts: 34
- Joined: Tue May 22, 2012 11:09 pm
Re: Java
Is that a version with JIT compilation?
Re: Java
On the Debian image, you can install the openjdk-6-jdk package, which will automatically pull in the icedtea-6-jre-cacao package. Then:Is that a version with JIT compilation?
- "java ..." runs Zero, which is an interpreter in the official OpenJDK JVM written by Gary Benson (http://gbenson.net/). It's portable, but very slow and can't JIT.
"java -cacao ..." runs Cacao, an alternative JVM which JITs.
I find Cacao to be 50 times faster than Zero in one small benchmark. The stability, reliability, compatibility, memory usage etc. remain to be seen.
Gary Benson also had a project called Shark which uses LLVM to JIT on various architectures. But LLVM doesn't support ARM when last I checked, so we can't use that yet.
There's also JamVM to consider, but I don't know how good it is. Debian doesn't seem to have a package for it either.
Re: Java
There exist two variants of Zero, the generic C++ interpreter variant built from OpenJDK directly and a mixed mode variant from IcedTea that is based on the OpenJDK variant with a ARM assembler interpreter and a Thumb2 JIT addon. http://www.raspberrypi.org/phpBB3/viewt ... 72#p103672dacha wrote:"java ..." runs Zero, which is an interpreter in the official OpenJDK JVM written by Gary Benson (http://gbenson.net/). It's portable, but very slow and can't JIT.Is that a version with JIT compilation?
Debian have packaged JamVM in Wheezy, its found in the icedtea6-jre-jamvm package.dacha wrote:There's also JamVM to consider, but I don't know how good it is. Debian doesn't seem to have a package for it either.
JamVM have some unique strenghts found in quick jvm statup time and low memory overhead.
Overview of various JVM variants on the Pi running the SciMark2 benchmark for numeric floatingpoint computations:
The OpenJDK tests in this overveiw was run using:
Code: Select all
wget http://math.nist.gov/scimark2/scimark2lib.jar
java -cp scimark2lib.jar jnt.scimark2.commandline
Code: Select all
wget http://math.nist.gov/scimark2/scimark2lib.jar
gcj -O2 -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=softfp -o scimark2 --main=jnt.scimark2.commandline scimark2lib.jar
./scimark2
- The current fastest way to run java code on the Pi is to use ahead of time compiation using GCJ.
- The current fastest JIT to use on the Pi is to use CACAO from IcedTea6 1.11.x on Debian Wheezy.
Xerxes Rånby @xranby I once had two, then I gave one away. Now both are in use every day!
twitter.com/xranby
twitter.com/xranby
Re: Java
It is a good question, There exist two variants of Jazelle:ctday wrote:I'm just starting to learn anything about the ARM architecture, so this may well be a stupid question - Do any of the JVM options available or pending make use of the Jazelle direct-byte-code-execution instructions? Thanks.
Jazelle v1 also called Direct Bytecode eXecution, DBX, this is the variant found in the Pi, unfortunally no complete documentation exist how to implement and make use of this runtime mode in software so i doubt any open source JVM will ever be able to use this runtime mode. DBX was designed to speed up startup time of JavaME to let the JVM run bytecodes while the JIT was initializing. To my knowledge you need to be a JTEK licensee to be allowed to use Jazelle DBX.
In reality i think JamVM+OpenJDK will start equally fast or faster than any JTEK/DBX enabled JVM.
Jazelle v2 also called Run-time Compilation Target, RTC, this is basically the Thumb2 instructionset. The OpenJDK+Zero Mixed Mode JVM with a Thumb2 JIT uses it. Jazelle RTC is designed to be a good target for any JIT computer language so its not even Java specific. Jazelle v2 exist in all ARMv7 cores and later.
Xerxes Rånby @xranby I once had two, then I gave one away. Now both are in use every day!
twitter.com/xranby
twitter.com/xranby
Re: Java
My software (a model railway control system written in Java) needs RXTX or similar (to connect to the interfacing hardware) and hsqldb (or some other JDBC SQL database).
I have started with Debian and OpenJDK-6
Zero is so slow its totally unusable (but it works, I think).
Cacao won't load the rxtxSerial.so (System.getProperty ("java.library.path") also returns null) and neither hsqldb1.8 or 2.0 works (different but disastrous exceptions).
OpenJDK-7 isn't available on Debian
sun-java isn't available on our architecture
A previous message said OpenJDK-7 is available on Arch but the discussion on Arch sounds as if its too buggy to use just yet.
Do I have any other choices?
I have started with Debian and OpenJDK-6
Zero is so slow its totally unusable (but it works, I think).
Cacao won't load the rxtxSerial.so (System.getProperty ("java.library.path") also returns null) and neither hsqldb1.8 or 2.0 works (different but disastrous exceptions).
OpenJDK-7 isn't available on Debian
sun-java isn't available on our architecture
A previous message said OpenJDK-7 is available on Arch but the discussion on Arch sounds as if its too buggy to use just yet.
Do I have any other choices?
Re: Java
Are you using JMRI?Howard wrote:My software (a model railway control system written in Java) needs RXTX or similar (to connect to the interfacing hardware) and hsqldb (or some other JDBC SQL database).
I believe you are trying to run a heavy swing application on the Pi to display the railway network.Howard wrote: I have started with Debian and OpenJDK-6
Zero is so slow its totally unusable (but it works, I think).
The slowness you see is most likely related to the fact that all java2d in openjdk have no choice but fallback to pure software rendering of all swing/awt gui, thus the slow operation is caused by the java2d backend and not the JVM itself.
I would suggest you to try some of the alternative java2d backends like try using the xrender backend across a remote ssh -X session. To activate xrender pass -Dsun.java2d.xrender=True to java when launching your application, it might help a little to speed up java2d.
I think you are currently using Debian "squeeze".Howard wrote: Cacao won't load the rxtxSerial.so (System.getProperty ("java.library.path") also returns null) and neither hsqldb1.8 or 2.0 works (different but disastrous exceptions).
OpenJDK-7 isn't available on Debian
If you instead try the new Debian "wheezy" beta, then this version contains a major updated, rewritten from c to c++ cacao 1.0.x version for use in combination with openjdk-6. openjdk-7 is available as well in Wheezy.
Oracle currently offer JavaSE embedded for ARMv6/7 Linux - Headless - this should work on the Raspberry Pi, It is a headless build without AWT/Swing so it should work unless you require an GUI.Howard wrote:sun-java isn't available on our architecture
http://www.oracle.com/technetwork/java/ ... index.html
You can try jamvm + openjdk that is also found in debian wheezy.Howard wrote:Do I have any other choices?
Xerxes Rånby @xranby I once had two, then I gave one away. Now both are in use every day!
twitter.com/xranby
twitter.com/xranby
Re: Java
No. Its my own software that I started around 1999. It has grown quite a bit since then.Are you using JMRI?
It is certainly a swing app, I don't consider it 'heavy' as the GUI thread uses only one quarter of the CPU that the whole app uses.I believe you are trying to run a heavy swing application on the Pi to display the railway network.
Correct. I have now downloaded Wheezy and openjdk-7 and its lots faster.I think you are currently using Debian "squeeze".
If you instead try the new Debian "wheezy" beta, then this version contains a major updated, rewritten from c to c++ cacao 1.0.x version for use in combination with openjdk-6. openjdk-7 is available as well in Wheezy.
Running plain java is a little faster than -cacao was on squeeze, and it seems to work (a few problems to sort out yet though).
java -cacao doesn't even get started (I get jmm_GetBoolAttribute: Unknown attribute 24) so thats something to look at later.
But I need a GUI to be able to see whats going on. But yes I knew it was available, just not applicableOracle currently offer JavaSE embedded for ARMv6/7 Linux - Headless - this should work on the Raspberry Pi, It is a headless build without AWT/Swing so it should work unless you require an GUI.

I don't particularly need fast startup or low memory usage - I still have half the memory free when its running.You can try jamvm + openjdk that is also found in debian wheezy.
Many thanks for your help - it has certainly moved me forward.
Re: Java
I was slightly hasty in my previous analysis.
Java on Squeeze was indeed a disaster for me.
On Wheezy most combinations (6 or 7, zero, cacao, jamvm) loads libraries and starts reasonably quickly so thats better than Squeeze but after a little the XAWT thread consumes all the CPU even if I just have a single, rather empty window open.
Catching stack traces every few seconds and saving them (in memory) it seems that the thread (called AWT-XAWT) is sun.awt.X11.XToolkit and it spends more time converting events to strings for disabled logging than it does dispatching events.
So I deduce we have a debug version of XToolkit in arm-openJDK. I guess there is nothing we can do about that until the openJDK team decide it works properly.
Java on Squeeze was indeed a disaster for me.
On Wheezy most combinations (6 or 7, zero, cacao, jamvm) loads libraries and starts reasonably quickly so thats better than Squeeze but after a little the XAWT thread consumes all the CPU even if I just have a single, rather empty window open.
Catching stack traces every few seconds and saving them (in memory) it seems that the thread (called AWT-XAWT) is sun.awt.X11.XToolkit and it spends more time converting events to strings for disabled logging than it does dispatching events.
So I deduce we have a debug version of XToolkit in arm-openJDK. I guess there is nothing we can do about that until the openJDK team decide it works properly.
Re: Java
Oracles Java2D team is aware of this bug, it is a generic bug and it triggers sporadically on many different systems and configurations:Howard wrote: On Wheezy most combinations (6 or 7, zero, cacao, jamvm) loads libraries and starts reasonably quickly so thats better than Squeeze but after a little the XAWT thread consumes all the CPU even if I just have a single, rather empty window open.
Catching stack traces every few seconds and saving them (in memory) it seems that the thread (called AWT-XAWT) is sun.awt.X11.XToolkit and it spends more time converting events to strings for disabled logging than it does dispatching events.
So I deduce we have a debug version of XToolkit in arm-openJDK. I guess there is nothing we can do about that until the openJDK team decide it works properly.
http://bugs.sun.com/bugdatabase/view_bu ... id=7105941
Unfortunately no known fix is available yet.
Xerxes Rånby @xranby I once had two, then I gave one away. Now both are in use every day!
twitter.com/xranby
twitter.com/xranby
Re: Java
Hmm.. looks like this bug trigger when trying to use the java2d xrender backend in combination with the framebuffer xorg driver on the pi. you may send this crash log, and possibly a reproducer, to the icedtea bugzilla and we can try figure out if the crash happened inside the xrender backend itself or inside the framebuffer xorg server.Howard wrote:P.S. I also tried the xrender=true suggestion.
JVM crash & bug file. Not so good
Xerxes Rånby @xranby I once had two, then I gave one away. Now both are in use every day!
twitter.com/xranby
twitter.com/xranby
Re: Java
Please double check your code to verify that all awt and swing code runs on the event dispatch thread. You do this by for example changingxranby wrote:Oracles Java2D team is aware of this bug, it is a generic bug and it triggers sporadically on many different systems and configurations:Howard wrote: On Wheezy most combinations (6 or 7, zero, cacao, jamvm) loads libraries and starts reasonably quickly so thats better than Squeeze but after a little the XAWT thread consumes all the CPU even if I just have a single, rather empty window open.
Catching stack traces every few seconds and saving them (in memory) it seems that the thread (called AWT-XAWT) is sun.awt.X11.XToolkit and it spends more time converting events to strings for disabled logging than it does dispatching events.
So I deduce we have a debug version of XToolkit in arm-openJDK. I guess there is nothing we can do about that until the openJDK team decide it works properly.
http://bugs.sun.com/bugdatabase/view_bu ... id=7105941
Unfortunately no known fix is available yet.
Code: Select all
public static void main(String[] args) {
createAndShowGUI();
}
Code: Select all
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});
}
http://docs.oracle.com/javase/tutorial/ ... index.html
Xerxes Rånby @xranby I once had two, then I gave one away. Now both are in use every day!
twitter.com/xranby
twitter.com/xranby
Re: Java
Now thats going to be a challenge. My app uses several threads (one to interpret a script, two per port handle serial port comms, one to compile another script, one to load images and more). It is entirely possible for some swing updates to have crept in considering the vast number of places that updates might occur.Please double check your code to verify that all awt and swing code runs on the event dispatch thread.
I had considered that working correctly on Mac and Windows, and previously working on Solaris and Linux meant that the code was correct. Silly me.
But thanks very much for that insight. I'll have to find some time to check the whole App now.
Re: Java
Done. Not as bad as I had expected! Now all GUI calls are in the event thread, including component creation which used to be allowed anywhere.Please double check your code to verify that all awt and swing code runs on the event dispatch thread.
I have used CheckThreadViolationRepaintManager to catch the bits I missed and now the only report is for JTextArea.append which is documented as thread safe.
Trouble is it hasn't improved the situation at all. Start the App and it does all its startup (at a good speed) and then the CPU usage goes down. Move the mouse pointer just a tad and CPU goes back to 100% and the whole system grinds so slow its like watching paint dry. No clicking, just the slightest mouse movement is all it takes.
-
- Posts: 1
- Joined: Sat Jan 28, 2012 5:57 pm
Re: Java
For java on Arch Linux:
uname -a
Linux alarmpi 3.1.9-22-ARCH+ #1 PREEMPT Sun Jun 17 13:54:30 UTC 2012 armv6l GNU/Linux
pacman -Q openjdk6
openjdk6 6.b22_1.10-1
compiler:
/usr/bin/javac
java -version
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10) (ArchLinux-6.b22_1.10-1-arm)
OpenJDK Zero VM (build 19.0-b09, interpreted mode)
from the Oracle website
http://www.oracle.com/technetwork/java/ ... index.html
Java SE Embedded 6
ejre-1_6_0_32-fcs-b05-linux-arm-vfp-eabi-headless-05_apr_2012.tar.gz
/opt/ejre1.6.0_32/bin/java -version
java version "1.6.0_32"
Java(TM) 2 Runtime Environment, Standard Edition for Embedded (build 1.6.0_32-b05, headless)
Java HotSpot(TM) Embedded Client VM (build 20.7-b02, mixed mode)
symbolic link for missing libffi.so.5
ln -s /usr/lib/libffi.so.6 /usr/lib/libffi.so.5
http://docs.oracle.com/javase/tutorial/ ... /unix.html
[root@alarmpi opt]# java HelloWorldApp
Hello World!
uname -a
Linux alarmpi 3.1.9-22-ARCH+ #1 PREEMPT Sun Jun 17 13:54:30 UTC 2012 armv6l GNU/Linux
pacman -Q openjdk6
openjdk6 6.b22_1.10-1
compiler:
/usr/bin/javac
java -version
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10) (ArchLinux-6.b22_1.10-1-arm)
OpenJDK Zero VM (build 19.0-b09, interpreted mode)
from the Oracle website
http://www.oracle.com/technetwork/java/ ... index.html
Java SE Embedded 6
ejre-1_6_0_32-fcs-b05-linux-arm-vfp-eabi-headless-05_apr_2012.tar.gz
/opt/ejre1.6.0_32/bin/java -version
java version "1.6.0_32"
Java(TM) 2 Runtime Environment, Standard Edition for Embedded (build 1.6.0_32-b05, headless)
Java HotSpot(TM) Embedded Client VM (build 20.7-b02, mixed mode)
symbolic link for missing libffi.so.5
ln -s /usr/lib/libffi.so.6 /usr/lib/libffi.so.5
http://docs.oracle.com/javase/tutorial/ ... /unix.html
[root@alarmpi opt]# java HelloWorldApp
Hello World!
Re: Java
OK, I've got my software running. I don't think the swing threading was an issue, but I am still 'fixing' issues as they arise.Please double check your code to verify that all awt and swing code runs on the event dispatch thread.
The killer turned out to be creating a JDBC Statement using HSQLDB (which was the database that I'd found worked best for me). Just commenting out:
Code: Select all
stmt = con.createStatement ();
Changing to the newer H2 database (written by the same person as HSQL) or to Derby (rather bigger and slower) it worked fine.
Re: Java
Happy to hear that your project is now running.Howard wrote:OK, I've got my software running. I don't think the swing threading was an issue, but I am still 'fixing' issues as they arise.Please double check your code to verify that all awt and swing code runs on the event dispatch thread.
The killer turned out to be creating a JDBC Statement using HSQLDB (which was the database that I'd found worked best for me). Just commenting out:Allowed the App to startup without XAWT going wild.Code: Select all
stmt = con.createStatement ();
Changing to the newer H2 database (written by the same person as HSQL) or to Derby (rather bigger and slower) it worked fine.
Please post a picture or write blog-post of your Pi Java controlled model train network this is so cool!

Xerxes Rånby @xranby I once had two, then I gave one away. Now both are in use every day!
twitter.com/xranby
twitter.com/xranby
Re: Java
If you go to http://groups.yahoo.com/group/mergtcc/ you can see a screen capture of my main track diagram window. But strictly my Tcc program does not define anything of what it does - it merely interprets a TCL (Train Control Language) script, handles serial port comms for several protocols (to different interface hardware) and gives the script control of various GUIs. My personal script does everything, including driving the trains, but of course that needs suitable external hardware. Some other people use it for route setting, and some for despatcher duty.Happy to hear that your project is now running.
Please post a picture or write blog-post of your Pi Java controlled model train network this is so cool!
The PI project I was working towards was for despatcher duty: keep track of train location and timetable to allow the human despatcher to respond to shunting and movement requests from all over the single track layout. The execution engine, the script, external SQL database and GUIs are all working well. Noticeably slower than on a Mac or PC but still usable.
Unfortunately I found that turning on the serial port (using RXTX) uses a *LOT* of CPU on the Pi and the whole package then ran rather too sluggish, even at 800MHz. I must try again now we have 1GHz available.
Making Tcc run on a Pi has been an interesting project because it brings back processing efficiency into ones consciousness. I have always tried to design things to run efficiently but some reworking recently (pre-Pi) meant that the GUI work for the main CTC windows (like the track diagram) was reduced to 40% of what it was previously. I have made some more modest gains while working on the PI.
What I have noticed is that just moving the mouse takes a *LOT* of CPU redrawing the pointer. Moving the mouse (only lxterminal and task manager running) takes the CPU from an idle 3% to 60-70%. This is with firmware downloaded a few days ago. Probably a bit of an issue for most mouse-using applications. I guess the USB driver that collects mouse input needs to regulate events into the system to no more than 10 a second. Whatever the issue is here I am confident that someone will come up with a fix before too long as it must affect most Pi-users.