JavaSE for iOS/Android to feature JavaFX

Let’s hope that this will improve Oracle’s view of consumers using java :slight_smile:

[quote]The first bits and pieces for iOS should be out next week, with the rest of iOS and Android coming out at about the same time as the rest of prism (there is some timing dependency there). Both our ports are based on an as-yet unreleased version of JavaSE Embedded for iOS/Android.
[/quote]
Source: http://fxexperience.com/2013/02/february-open-source-update/

Mike

I couldn’t care less really, what I want to know is, how is the JVM part going to work?

Cas :slight_smile:

yeah quite interesting^^

I also think that all the tech which goes into java fx would be quite cool for us.

I for example stumbled over jsl. A own shader language for effects, which they can compile(Decora compiler) to OpenGL, D3D and Java(software mode).

It would be also quite nice if we could finaly use a real ui framework in our OpenGL games.

It should be not that hard to implement javafx with JOGL or lwjgl, especially when everything is opensourced in a few weeks.

Using the OpenGL backend from java fx would be even better, no need for hacky things like libgdx is doing atm to get things running on android & ios.
This should give us probably also a speed up on android when we get to us a “real” javaVM on there

ps:

the say that they have an undisclosed Java SE Embeeded VM for iOs and Android. And that it will be first available with OpenJDK and OpenFX.

As it’s actually enforced by iOS that apps can’t execute data or turn data pages into code pages AFAIK I’d be rather interested to see how the JVM works. Unless of course it is a pure interpreter in which case it’s about as useful as a chocolate fireguard.

Cas :slight_smile:

is there a difference in the rules for the iOS appstore and the one for the Mac?
Because the already published the JavaFx sample app to the Mac appstore

Never mind the Mac desktop, Java is already alive and well there.

Cas :slight_smile:

[quote=“Danny02,post:3,topic:40994”]
What kind of ‘hacky things’ is LibGDX doing in the Android backend?

[quote=“davedes,post:7,topic:40994”]

It’s almost like he’s suggesting using Dalvik is hacky - he might be right! :wink:

I think he was making the point about the app store rules on the desktop, and how similar (or not) they may be to the iOS ones. Apple allow apps that use OpenJDK in the desktop app store as long as they ship with the VM included. I wonder if that Oracle announcement means that they expect the same to hold for iOS? It also talks about using OpenJDK with OpenJFX to target Android and iOS - no mention of whether they’re open sourcing a VM with decent speed on ARM though!

Oracle aren’t stupid and neither are we. It’s going to either ship with Zero, and it’ll be a complete laughing stock; or they’ve developed an AOT compiler and VM runtime. I’m hoping for the latter.

Cas :0

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.

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:

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]

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.

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

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

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:

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.

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:

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

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.