JavaFX and iOS - it will remain a dream

Tom Schindl tom.schindl at
Tue Jul 30 23:28:33 PDT 2013

I don't think it is a good idea to use fxml on embedded and mobile, we are working on a fxml => java converter so you can add it to your build process.


Von meinem iPhone gesendet

Am 31.07.2013 um 08:11 schrieb Niklas Therning <niklas at>:

>>>> after many days trying to really build iOS apps with JavaFX and RoboVM
>> or
>>>> Avian I’m very frustrated because of the following things:
>>>> Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know
>> the
>>>> reason - maybe it’s the rendering model of JavaFX - maybe it’s the
>>>> currently unoptimized RoboVM
>>>> One big problem of RoboVM is it’s dependence of the Android library, it
>>>> does not support the OpenJDK. That’s a big reason for many many
>> problems
>>>> when using JavaFX. So currently it’s not possible to use fxml files
>>>> (FXMLoader) because of the missing Stax xml parser and classes like
>>>> XMLInputFactory in the android library…
> There's now a compatibility library for the jfx78 backport which includes
> the missing sun.* classes from OpenJDK [1]. So that will not be a problem
> when running on RoboVM/Android. Daniel Zwolenski is working on getting this
> into Maven which will make it nice and easy to develop with RoboVM+OpenJFX.
> FXMLLoader relies an StAX and the Java Scripting API. Those can both be
> made to work on RoboVM/Android. The POM of the compat project [1] contains
> optional dependencies on the StAX API and JSR 223 API. For StAX you'll also
> need a StAX provider [2][3]. For scripting you'll need a JSR 223
> implementation of the scripting language you're using, like Rhino for
> JavaScript [4][5]. Please note that I haven't tested FXML but it should
> work (in theory at least ;-) ). Please give it a go. It will be a great
> blog story if you can make it work on iOS.
> As for the performance issues with RoboVM+OpenJFX: those WILL be addressed!
> You can either wait for it to happen or you can help out. One way to do
> that would be sample code that exercises the code paths that need to be
> optimized (e.g. the button rendering you posted about earlier). Preferably
> the sample should run repeatedly without user interaction. You should then
> be able to run Apple's Instruments application to profile this sample. This
> will help us determine what needs to be optimized.
> /Niklas
> [1]
> [2]
> [3]
> [4]
> [5]

More information about the openjfx-dev mailing list