JavaSE for iOS/Android to feature JavaFX

General Discussions
#10

Interesting, thanks for the link Mickelukas.
I did some research and it looks like Oracle have 2 JVM’s for ARM, both of which use openjdk 8 class libraries, but the ‘embedded’ version features an optimised hotspot VM, while the ordinary version still has a hotspot VM, but is not optimised for ARM. See Henrik’s post in this thread (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=81&t=27805):

[quote]by henrik » Tue Jan 01, 2013 6:24 am
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)

Henrik Ståhl
Sr. Director, Product Managament
Java Platform Group, Oracle
[/quote]
Richard Bair also posted a performance comparison of JVM 8 vs GCC on the RPi, and java is faster: http://fxexperience.com/2012/12/javafx-on-raspberry-pi/.
I think the JVM hotspot version he is using is ‘embedded’ since the file name has an ‘e’ in the ‘b36e’ build number: http://www.java.net/download/JavaFXarm/jdk-8-ea-b36e-linux-arm-hflt-29_nov_2012.tar.gz

Hopefully Oracle eventually opensource all of the embedded hotspot VM. But if they don’t, at least we have an ordinary hotspot VM for ARM.
According to the post linked to by Mickelukas (http://fxexperience.com/2013/02/february-open-source-update/):

[quote]…we do not yet have iOS / Android on our official release roadmap, so that for the time being, the only way to use JavaFX on iOS is via OpenJDK / OpenJFX. I can imagine this would make open source guys smile (open source goes where closed source does not!). This is also why we’ve been prioritizing open source so highly for the last little while — when OpenJFX can be built without any binary stubs, then there is nothing stopping you from taking OpenJFX with iOS port + OpenJDK and creating commercial applications that can be sold in the iOS app store.
[/quote]
So that means that any VM on iOS or Android will have to be a derivative of the open-source openJDK 8 and not the close-sourced ‘embedded’ version, which means that iOS and Android will be running the slower unoptimised hotspot JIT.

#11

And thus rubbish. And on iOS, they can’t even use JamVM or Cacao JITs, so it’ll have to be pure interpreter only.

Cas :slight_smile:

#12

It would be interesting to see a performance comparison of the two hotspot VM’s. I haven’t got a raspberry Pi to test.
There’s a chance that the performance difference is not large. Especially considering that a lot of our game code will execute openGL stuff which is not done on the CPU, the performance of the embedded hotspot JIT compiler might only result in a small performance benefit over the ordinary hotspot JIT compiler. Also, both use ARM hard float.

Why can’t they use JIT’s? According to Richard Bair from Oracle (http://fxexperience.com/2013/02/february-open-source-update/):

[quote]There have been some question about licensing on iOS as Apple doesn’t allow for GPL licensed applications in their app store. OpenJFX and OpenJDK are both licensed with the same GPLv2 with Classpath Extension. My understanding (and I’m not a lawyer) is that this means that if you take OpenJFX + OpenJDK (minus any binary stubs released under a different license), then you can safely combine this with your application and release your application under your own license as a single application co-bundle.
[/quote]

#13

It’s nothing to do with licensing. All JITs execute code from from data segments, which is forbidden by iOS and Windows 8 RT. Nitro and IE10’s JIT work on those OS’s because the vendor special-cased them.

#14

Ah i see, thanks. Well, that sucks about iOS.
At least android apps will benefit.

#15

Oracle will work out a deal on Windows 8 RT too! Can’t lose to Adobe.

#16

It’s all about the one single whimsy of Apple. They’ll either special case it - or not. If they don’t - the Zero VM is worthless. Unfortunately CommanderKeith the Zero VM is so slow you’re not going to be doing anything much exciting with it, unless you like watching loading screens. It will be so farcically poor that the Java platform will simply be laughed off of iOS, and rightfully so. I’ve got a RPi here and I can tell you that the Oracle Embedded VM is approximately 5x faster than anything else out there, and that makes a hell of a lot of difference on the sorts of chips you find in iPhones.

When you look at the quality bar that native C++ applications are setting on ARM based systems you’ve really got to have a good VM to compete with them.

Cas :slight_smile:

#17

I bet they use Zero on iOS. Reason being that JavaFX “does all the heavy lifting on the GPU”, which is of course bullshit. I also wonder how interop with native UI APIs is meant to be done, e.g. integration of IAP dialogs, advertisement etc. If they ship their own VM on Android, that might be an interesting excercise in frustration, having both Dalvik and their VM coexist and communicate.

#18

I expect they’d coexist just fine - Android can just talk natively to C after all so it can talk to a normal JVM via JNI. Seeing as JDK7 embedded is so much faster than ordinary Dalvik I wonder why I’ve not tried it myself yet. Hm.

Cas :slight_smile:

#19

Having to wrap Android APIs via JNI to call into them from Oracle’s VM sure sounds like an efficient use of someones time.

#20

That’s too bad. Apple really makes things hard. What is frustrating is that even if someone got around Apple’s ridiculous restrictions and managed to make iOS run java (or any other cross-platform language), then Apple would change their software or license to forbid it, in the name of security/compatibility/user experience, when really their underlying motivation is to have captive developers and programs.

By the way, kudos to badlogicgames for being that person to make libgdx/java run on iOS. But I notice that it still requires devs to buy into the apple tool-chain.

#21

From the perspective of Apple users and shareholders…they’re doing it right.

#22

I’ve got no problem with paying money to use the Apple toolchain… I just want to use the tools I’m best at. It’s true that Apple and Oracle could easily sort this particular problem out to the benefit of everybody. Hell, I’d even pay a license for the JVM per product if that’s what it came to.

Cas :slight_smile:

#23

It might be cheaper just to pay someone to port your stuff to a C family language and call it a day.

#24

As it happens we’ve got someone doing Monkey ports of Titan Attacks but the point is I want to do it myself and I don’t really see why Java should be getting in my way. I could surely do it in C++ from scratch and it wouldn’t take a million years but I have better things to do than porting code that’s perfectly fine in the first place.

Cas :slight_smile:

#25

I still hesitate in spending time in resurrecting the JOGL backend of JavaFX. I will do so if and only if OpenJFX is really free software, if we can freely ship OpenJDK on embedded systems.

#26

And it’s all the more annoying that from time-to-time something promising pops up and then stalls before it becomes interesting.

#27

Yes, must have happened about 5 times now. I actually hold out a bit of hope for Excelsior here - they’ve got half the expertise required to do it but apparently finding smartypants ARM engineers is no easy task.

Cas :slight_smile:

#28

Looks like shit’s getting real: https://bitbucket.org/openjfxmirrors/openjfx-8-graphics-rt/src/008bdab5b9fbd5c56ace638874141cfc83be69d3/glass/glass-lib-ios/src/GlassApplication.m?at=default

#29

I’ve said it before: JavaFX is great for data and widget-centric GUIs with checkboxes and grid controls. For game development you want an API like OpenGL that gives you a way to render polygons with hardware acceleration. JavaFX just isn’t designed for that.