oracle embedded JRE preview
pros: seems to be the fastest option, supplied class libraries include accelerated javafx implementation. 
cons: propietary, doesn't appear to be redistributable, still prerelease, supplied class libraries are jdk8 based and don't include AWT/swing (though apparently the oracle embedded vm can be used with the class libraries from raspbian openjdk to get AWT/swing support). 
forum thread: viewtopic.php?f=81&t=26110

That should be "Oracle JDK 8 preview for Linux/ARM".  Our Java SE Embedded products (that you call the embedded JRE) is a commercial variant optimized for low memory footprint. 

A few clarifications:
- All implementations use the OpenJDK class libraries, but with different VMs
- OpenJDK is developed by Oracle and other members of the OpenJDK community
- The Oracle JDK is based on OpenJDK, adding a few features that we either don't have the right to open source or that we keep closed for commercial reasons.  For now that includes our ARM port of Hotspot, which is highly optimized. 
- Oracle JDK binaries undergo extensive testing and are likely the highest quality. 
- Oracle JDK is free (as in beer) for most purposes including redistribution with applications, see the license agreement you click through to download JDK 7
- The Oracle JDK 8 preview is under an early access license with more reatrictions
- Using the Swing/AWT libraries from OpenJDK 7 or Oracle JDK 7 with the JDK 8 preview is unlikely to work moving forward, but you can always compile OpenJDK 8 (our binaries and the OpenJDK source are kept in sync)
- JavaFX is partially available open source in the OpenJFX project on java.net, and will be fully open sourced over the next few months (including the ARM port)

While i know that compilation can be tricky i have prepared a RaspberryPi armhf CACAO libjvm.so that you can use as an drop in replacement into any OpenJDK 6 installation (/usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/server/libjvm.so) This libjvm.so was built using the icedtea6 1.12 release from inside a Raspbian chroot. 

Unfortunately it seems the new version failed to build on both armel and armhf in debian with different failures.  Any thoughts? ( i'm trying a build on raspbian anyway but I wouldn't be surprised if it fails too

Unfortunately it seems the new version failed to build on both armel and armhf in debian with different failures.  Any thoughts? ( i'm trying a build on raspbian anyway but I wouldn't be surprised if it fails too

Was this reported from the official armel Debian builders? 
having access to the /build/buildd-openjdk-6_6b27-1.12-1-armhf-y7c3I9/openjdk-6-6b27-1.12/build/hs_err_pid2433.log do help if possible. 

So this looks like an internal crash inside the ARM32 assembler interpreter port that is an extension on top of zero for ARM OR the generic OpenJDK zero vm (they both use unfortunately the same version number string when run on hardware without Thumb2).  These bugs are hard to track down, usually happens inside the 10K line handwritten ARM assembler interpreter addon for Zero. 

If the bug is persistent then A) try switch the default JVM powering OpenJDK6 used by the buildd to JamVM. 
(edit /etc/java-6-openjdk/jvm-armhf.cfg on the builder and make sure
-jamvm KNOWN
is on the top)

or B) disable zero for the build edit the debian rules for armel and armhf and make jamvm the default jvm.  it might be a problem with Zero for the 6 1.12 release because Oracle do not test Zero at all, for what I know, in OpenJDK upstream and the IcedTea release team only got limited testing of zero on different platforms.  So the safest bet is to disable Zero. 

All in all I will try reproduce and if I can reproduce it then file a bugreport with the IcedTea team. 

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

armel still fail to build because Debian soft-float armel target armv4t while the CACAO assembler part of the code used a BLX armv5+ instruction.  This is easily fixed the key is to replace the
BLX ...
with a
mov PC, LR
BX ...
instruction pair, BLX is only a compact assembler instruction found in armv5 and later to do a backup of the PC register into the LR and branch using the same instruction.  This needs to be fixed with cacao upstream.  And nothing for Raspbian to worry about since we target armv6 that include BLX! 

In-order to use the alternative JVMs such as JamVM, CACAO and Avian in combination with OpenJDK pass the jvm name as the first argument on the command line to java; example:
java -jamvm -version
java -cacao -version
java -avian -version

You can set the default to use for OpenJDK 6 by editing the
/etc/java-6-openjdk-armhf/jvm-armhf.cfg

You can set the default to use for OpenJDK 7 by editing the
/etc/java-7-openjdk-armhf/jvm-armhf.cfg

The alternative OpenJDK JVM are installed under /usr/lib/jvm/java-7-openjdk-armhf/jre/lib/arm under a folder named after the respective alternative JVM.  The jre/lib/jvm.cfg tells the OpenJDK installation which folders are valid JVM names. 

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

I installed oracle jdk 8 to use hardfloat. 
Now I red on the rpi site that jdk 7 is now ready for arm with hardfloat. 
I follwed the instructions on the site, sudo apt-get install oracle-java7-jdk but the jdk8 is still
alive. 
How can I un'install it? 

If you design a graphical application then the most important choice on the Raspberry Pi is to pick an API that can take advantage of the Broadcom VideoCore GPU graphics processor. 
The PI CPU runs at 175MFlops while the GPU runs at: 2600MFlops thus picking the right API makes up to 15 times performance difference!  Also the JVM running on the CPU will handle events such as input better if all graphics rendering is offloaded to the GPU.http://elinux.org/Raspberry_Pi_VideoCore_APIs

Afaict the oracle VM is the fastest if you are prepared to accept it's license. 

That sounds a bit scary scary, so let's be clear.  It's the same "free-as-in-beer" license (for usage and redistribution for most use cases you can think of) that we use for desktop and normal server-side Java.  No developer or hobbyist should be remotely concerned about accepting it. 

"Like all general-purpose JDK and JRE binaries, the ARM JDK is free for development and production use on general-purpose hardware, and can be redistributed for free with applications targeting a general-purpose computer.  See the end-user license for the exact license grants & restrictions.  To take a couple of examples, an ARM server deployed in your datacenter running Tomcat or Glassfish is general-purpose, as is a Raspberry Pi board when you use it like a PC.  An industrial controller or a kiosk appliance is not general purpose, and both would require a commercial license."