JAVAFX on ANDROID

[Matthias Hänel]

Hi Richard,


thanks for your fast answer.


Am 11.10.2013 um 18:53 schrieb Richard Bair <richard.bair at oracle.com>:

> As frustrating as it is, the fact is that today Oracle has no announced plans to release any official JVM for Android and iOS. That being the case, the biggest hurdle to getting FX on iOS and Android is the VM. On the iOS side there has been some success with RoboVM. On Android you can just use Dalvik if you back port to Java 6, or you have to find another VM (XMLVM maybe?? Anybody convince Excelsior to support Android?) that can do the job.

The main point of irritation comes from an quite unclear position about providing the JVM and JFX of the Java-platform. 
That's why I will sumarize what I heard between the lines:

1. there is NO official jvm planned for iOS and Android in the near future.
2. jfx8 is beeing officially maintained until some point for iOS and Android but the actual port is left to the open source community.
3. Linux ARM support is beeing focused officially on the Freescale ARM-platform.

our conclusion is:
1. that's not that bad anymore since we have RoboVM for iOS and Davlik on Android.
2. this statement should have been made 1 year ago. Probably, I missed it but it was not clear to my team as well until last week.
   That's why we took the challenge to do it our selves.
3. This is good for the open source development since we probably can rely on the CPU optimized parts for ARM.



> There are two parts the problem of a "VM". One is the VM technology itself, which is probably the lesser of the two issues because there are a handful of decent VMs around (if you include Dalvik, you've already got one on Android). The second problem are the class libraries. Generally JavaFX doesn't rely on too much from JavaSE beyond what is in the "base" module; threading and collections and concurrency and so forth. However we are using the diamond operator and in a few places we might use multi-catch (although I don't know of such places myself) and definitely we use default methods in interfaces in one location (ObservableList). Generally we've tried to make it easy to back port to 7, but haven't tried to keep 6 up to date. I would be very interested in the list of code changes Matthias had to make to better understand the situation.


Yes, mainly it was the multi-catch stuff and the diamonds and some default methods. It's still enough to maintain ;)


> As far as fonts (from Matthias' email) I believe the Android port currently uses T2K but Felipe and Tomas were talking about using the new Font support which would delegate directly to Android APIs. This might be one area that Matthias' and Felipe and Tomas can work closely on to get a contribution to make this happen!

I have seen T2K in the ARM-Linux port but it's not in the sources since it's one of the libraries that are still in the closed parts of OpenJFX.

Is there a fallback? Pango doesn't work either it's not used in the android gradle scripts. 
I would be happy to integrate it and I am sure I can compile pango for android. I just need a pointer to how I can integrate it into the build process.
I changed android.gradle but I am not sure where to put the pango sources.



>> How much time do you think it would take community designers to develop this?
> 
> RoboVM for iOS I think is basically at this stage, where they've got something up and running to the point of being able to do performance analysis and looking for bugs. It has been a several month process with stops and starts. Tom and the others working on RoboVM might be able to give a better estimate.
> 
>> Does it support swing and javafx or just javafx like the Pi port? What parts of java8 don't work on your standalone VM?
> 
> I couldn't tell you what does / doesn't work on the standalone VM as that would break all kinds of confidential legal mumbo-jumbo. But I can tell you I've never seen a port of AWT to iOS or Android.




kind regards
Matthias