Jitb - Java Based Flash Player

[fraseyboy]

http://blog.joa-ebert.com/2010/08/19/introducing-jitb/

Potential Pandora compatibility?

 

[emil10001]

Does Java run on the Pandora?

 

[Ollonk]

There are open source Java programs for Linux/Ångstrom, though I'm not sure that they have been tried much on the Pandora. (And they are community efforts, not sponsored by Sun.)

EDIT: A quick search came up with IcedTea, which is what I was thinking of. And also JAMVM has a topic.

http://www.gp32x.de/board/index.php?/topic/52083-java-runtime/
http://www.gp32x.de/board/index.php?/topic/49691-icedtea-java/
http://www.gp32x.de/board/index.php?/topic/51668-jam-vm-support/

 

[fraseyboy]

Java Embedded:
http://www.oracle.com/technetwork/java/embedded/overview/index.html

It says it works on ARM...

 

[Ollonk]

By ARM they probably mean phone OSs and Windows CE/Mobile/etc.

 

[Letalis Sonus]

not sponsored by Sun.

You mean Oracle (who's currently trying really everything to backstab the community around many of their acquired open source projects...)

It shouldn't be much of an issue to get Java onto the Pandora, there are even OpenJDK Debian packages for ARM, but the question is how well it would perform.
More interesting would be the question how far those nice Java-boosting features of the Cortex-A8 could be used like the hardly documented Jazelle extension (native execution of Java bytecode) and ThumbEE (processor mode optimized for JIT compilers).

And then there's still Lightspark, yet another new open source flash player written in C++ that is using OpenGL/GLSL for rendering and a LLVM based solution for ActionScript. The problem is: All those new flash players are still so incomplete that they are rather useless for the end user, it is still better to rely on Gnash even if it might be slow at some points.

 

[Nod51]

http://www.bugcommunity.com/wiki/index.php/Try_openjdk_with_jazelle ? and adding some pointless text as there is nothing else to say except whats in the link, unless you want me to fill up the boards with copy and paste and/or get to enjoy listening to myself babble about something that is entirely in the link. Having said that I guess I could have linked to something irrelevant but added a comment so people would happily follow it, as opposed to just a possibly useful link (aka the ?) with no comment.

Edited: added useful comment

 

[dflemstr]

Jazelle won't work on the Pandora since it's proprietary (Nod51: I didn't actually look at what you linked to, only the URL)

J2ME is not what we want because it's a reduced version of the standard Java platform that isn't compatible with anything.

Java Embedded is what Oracle is trying to sell to new phone manufacturers: they make specialized JVMs for those platforms.

What WE want is the package openjdk-6-jre installed by default. It includes everything we need: a fast JVM, the core libraries, and various plugins and metadata.

OPT, thing to put in the next firmware maybe?

 

[Nod51]

Jazelle won't work on the Pandora since it's proprietary (Nod51: I didn't actually look at what you linked to, only the URL)

J2ME is not what we want because it's a reduced version of the standard Java platform that isn't compatible with anything.

Java Embedded is what Oracle is trying to sell to new phone manufacturers: they make specialized JVMs for those platforms.

What WE want is the package openjdk-6-jre installed by default. It includes everything we need: a fast JVM, the core libraries, and various plugins and metadata.

OPT, thing to put in the next firmware maybe?

And it looks like OpenJDK may have Jazelle, though not sure how legal or buggy it is...

 

[WizardStan]

OPT, thing to put in the next firmware maybe?

The openjdk packages amount to about 30MB additional storage. The NAND as it stands only has about 100MB left. They need to be very careful about what gets added.
jamvm is about as good (as far as I've seen) in only 10MB.

 

[Letalis Sonus]

Jazelle is a feature of the CPU and as such not proprietary, They only hold back documentations about it.

Actually, I stumbled upon a developer blog about work being done on ARM-optimized JIT compilers for IcedTea6, and this was posted in Feb 2010:

Edward Nevill created a ARM Jazelle RTC Thumb2 JIT reference implementation

Meanwhile I have been busy taming Sharks a new kind of Thumb2 JIT have emerged built by Edward Nevill of Cambridge Software Labs! The new Tumb2JIT have been committed into the Icedtea6 trunk and it are a working implementation of Jazelle RTC to be used by ARM Cortex-A8+ class CPUs. It wonderfull that this have been released as free software, Wow!,

Suddenly we got three different JITs to use on ARM with OpenJDK: Cacao, Shark and T2. An opurtunity has emerged to tier them and so I did. Here comes the raw “truth” produced by Caffeine Mark 3! This will probably be the last time i will show off any Caffeine Mark 3 benchmark since it really dont give justice on real world client applications where responsiveness are more crucial than top runtime speed, nevertheless benchmarking using CM30 have always felt fun so here we go: All benchmarks running using a Sharp PC-Z1 Cortex-A8 Mobile internet tool.

*benchmark result pic*
Tier between Edwards Thumb 2 JIT , Shark LLVM JIT and Cacao JIT: All running on a ARM Sharp PC-Z1 Mobile internet tool smartbook using OpenJDK 6 compiled with Icedtea6.

This new T2 JIT’s main strenght are reduced jitting time, it basically cuts all jtting time to almost zero and client applications on ARM finnaly runs from tick one. This thumb2 jit makes a really nice java applet browser experience with about 15 seconds first applet startuptime on a ARM smartbook and and all usable instantly after being loaded.
A small 1min 12seconds .3gp movie displaying some java applets running on the Sharp PC-Z1 featuring the new thumb2jit from Icedtea6

Cheers and have a great day!
Xerxes

 

[TitanUranus]

OPT, thing to put in the next firmware maybe?

The openjdk packages amount to about 30MB additional storage. The NAND as it stands only has about 100MB left. They need to be very careful about what gets added.
jamvm is about as good (as far as I've seen) in only 10MB.

Wasn't there recently some discussion about compressing the executables and libraries to gain an extra 100 mb or so? If that was done we could bung openjdk in there no problemo...

 

[urjaman]

Wasn't there recently some discussion about compressing the executables and libraries to gain an extra 100 mb or so? If that was done we could bung openjdk in there no problemo...

Wasnt UBIFS already compressed?
The uncompressed FS is already over 512MiB

 

[dflemstr]

OPT, thing to put in the next firmware maybe?

The openjdk packages amount to about 30MB additional storage. The NAND as it stands only has about 100MB left. They need to be very careful about what gets added.
jamvm is about as good (as far as I've seen) in only 10MB.

Wasn't there recently some discussion about compressing the executables and libraries to gain an extra 100 mb or so? If that was done we could bung openjdk in there no problemo...

JamVM won't lead to any minification of the Java core libraries, which are in a separate package. The VMs by themselves don't use up much space, so that's why one might think that using JamVM instead of the OpenJDK default VM will lead to less used disk space, because JamVM doesn't have an explicit dependency on the core libraries. But, alas, you still have to install the core libraries even when using JamVM, making the disk space differential significantly smaller.

Also: the current firmware is extremely wasteful (space-wise) as far as I've been able to determine (without having looked at recent reincarnations of it); it includes ImageTech 3D demos, Ubuntu Netbook Launcher, a non-streamlined kernel etc... Feel free to prove me wrong if you are in possession of a recent/working rootfs and are able to determine which parts of it are used how often etc.
The point of course being that having a working Java runtime in the firmware won't be as problematic as one might think once one realizes that the current firmware image (most probably) can be minified by 10-50% while retaining the same functionality.