JavaFX has made headlines lately as the (alleged) victim of a raging internal battle at Oracle between the SE and ME client teams, who are accused of trying to push HTML5 MAF (Mobile Application Framework, formerly ADF Mobile) and Java ME on mobile platforms. So it’s great news for the many JavaFX-aficionados out there that elsewhere in the techsphere, support for the technology couldn’t be stronger. Just today, Java-iOS specialists Trillian Mobile has announced that they will be partnering with Java specialists LodgON to bring JavaFX to their software. You can expect a stable release of JavaFX for mobile and iOS and Android around Q2.
For the uninitiated, RoboVM, created and sold by Trillian Mobile AB, is an open source mobile development tool which allows you to translate Java bytecode into native ARM or x86 code for iOS, Mac OSX and Linux. It comes with a Java to Objective-C bridge that taps into native iOS CocoaTouch APIs. Objective-C objects can be used just like any other Java object. With this new partnership, RoboVM services (currently at 1.0.0 beta 3 status with Trillian’s signature software) will be extended to include JavaFX in the mix.
In an interview with Voxxed, LodgON CEO Johan Vos stated that the partnership – which first came together at JavaOne 2014 – is using “the same JavaFX 8.u40 version, with all the new things that are in 8.240 early access on desktop – so accessibility, dialogue, and so on – that runs on Android and iOS with the same code base. Both mobile platforms are at the same level now.”
This last point is important, as, up until now, building JavaFX for mobile has been a cumbersome process for developers. Expanding on this, Vos comments that, “We didn’t have good tools, it required some manual building and downloading stuff, and configuring. We dramatically improved this. We created the Gradle plug-in that will download, install and configure everything, and if you have a JavaFX project, with Gradle you only need one line that you have to introduce to your build file, and then automatically the Android and the iOS artifacts will be built as well.”
According to Vos, “Before our collaboration, if you wanted your JavaFX application to run on Android, you needed to download this…configure that…and if you wanted to run it on iOS, you needed to create a separate project. So each of the ports had their own way of building it – and we greatly simplified it and made it possible to integrate them with your favourite IDE. It’s definitely helping developers, so we hope that we can get more JavaFX mobile developers with this collaboration.”
Although LodgON and Trillian Mobile met back in September, work on this project only really kicked into gear a month ago. Whilst it’s early days, the developers behind the project are eager to get this news out, with RoboVM creator and Chief Geek Niklas Therning stating that, as of now it’s a, “good time to start using it – you can start developing your JavaFX apps using this, you can run it on a desktop, and you can test it on Android and iOS now.”
From this point, if there’s anything performance wise, rendering glitches, etc., Therning and Co. want know that so we can fix it before they issue a stable release. Therning declares that, “it’s time to start building stuff using JavaFX, because in the next couple of months, this will be ready for actual deployment – publishing apps in the Google Play Store and on the Apple App store”
Allaying any worries developers might have about performance, Vos points out that JavaFX is structured in such a way that it leverages the GPU as much as possible, and as a consequence, you run directly on the EGL layer of Android – so all the rendering happens directly in OpenGL, meaning it’s as fast as a native application. Although that’s not to say that efforts won’t be made to optimize JavaFX with RoboVM. And once the community input comes in, RoboVM and LodgON will respond accordingly.
Trillian Mobile Co-Founder Henric Müller does chime in that there may be some concerns about the fact that, at present, JavaFX apps for iOS and Android are few and far between, and UI components for mobile remain scarce. But, as he says, “that is something that we will also see coming either from the community, or us, or companies that we will work with. Most other components like buttons, lists, etc., look very desktop as we just take the same Java face up. So we need to do some work there looks more iOS-like.”
All enterprise activity around this JavaFX mobile initiative will be done by Trillian Mobile, but both parties are resolute that everything remains open source. Vos compares this set-up to the Oracle-Java status quo, commenting that, “you can see that Open JDK, which is where the source code of the Java virtual machine is created and then Oracle distributing and selling support packages for it, I think JavaFX ports are the place where the code is written, and Trillian is the entity that commercialises it.”
With this project in place, developers now have options to bring their JavaFX apps to Android and iOS, and, as Therning tells us, “If you want to go the native route, you can build your native app in Java, you can use the native APIs and stuff, and get a native UI, etc. Both for Android and iOS – and still share some of your code. If you want to get 100% code sharing between all of the platforms, you can instead take the JavaFX route. So it’s something that will add to the platform.”
He adds that, “We’re still giving the developer the option for how to build their apps, and you will still need to have the native support for each of their platforms, because there will always be things that you might want to do, like accessing native services – for instance, using the GPS on an Android phone is very different from how you would use the GPS on an iOS device. If you wanted to do that, you might have to break out of the JavaFX independent layer and do something platform specific. When you do that, you can use the thing that you had before to access the native APIs on iOS – and then on Android, you’d use Google’s APIs for that.”
In the future, Therning predicts that there will be more wrappers, saying that it would be nice if you don’t have to provide, for example, separate GPS for each platform, and believes at some point Trillian Mobile and LodgOn can provide those kind of APIs, as well as put a specific layer over the platform – the sensors and everything. And then there’s the matter of keeping up with every latest Oracle release, from JDK 8.240 onwards. So plenty to be going on with for now.
Whilst for now RoboVM only provides support for Java, it is possible to use it with any language that compiles down to Java bytecode, such as Groovy, Scala, or Kotlin – and extending support for these languages is definitely ahead at some point on the roadmap.