JavaFX and Android

I think we can consider JavaFX to be stable on the desktop, and that is a very important fact. However, the client-side in the IT industry in general is shifting from desktop to mobile. Platforms need to have an answer for this. That is why I started a community project for porting JavaFX to the Android platform a couple of months ago.

When JavaFX 2 was announced, many developers and analysts said its success would be dependent on the ability to run JavaFX applications on mobile platforms. Today, we see that Oracle has done a great job in making JavaFX available on all major desktop systems (Windows, MacOS and Linux) and on embedded systems. The mobile area, including phones and tables, however, is not covered by Oracle. As far as I'm aware, there is no official explanation from Oracle on why mobile platforms are not (yet) officially supported. I'm not happy with that decision, but complaining about it is not going to help.

Developers are usually better in doing it themselves than in complaining. With the JavaFX code being open sourced over the past years, and with lots of work already being done by Oracle people, a community-effort for porting JavaFX to mobile platforms turned out to be a viable option.

I have some experience in porting efforts, as I was part of the Blackdown team porting Java to Linux. One of the things I learned is that the community has the power to drive innovation. Big companies might jump into the area later, and I am very ok with that. The Blackdown team became rather obsolete once Sun Microsystems started to invest in Java on Linux itself, and that was a nice way to become obsolete.

Since RoboVM is already doing great work on the JavaFX iOS port (see http://www.robovm.org and consider becoming a sponsor!), I decided to focus on the Android port. I talked with JavaFX architect Richard Bair during Devoxx, and got a jump-start thanks to Tomas Brandalik who already did lots of work on the native parts and Stefan Fuchs who maintained the Java 7 backport. After only a few weeks, we delivered a JavaFX Runtime for the Android platform.

The JavaFX Android community project is hosted at https://bitbucket.org/javafxports/android/wiki/Home and it contains instructions on how to run JavaFX applications on Android. The code is currently available at https://bitbucket.org/javafxports/android-graphics-rt . This repository is a mirror of the openjfx-8-graphics repository that is used to build the main JavaFX 8 code. Based on this code, a JavaFX Android runtime is created and available for download at https://bitbucket.org/javafxports/android/downloads/dalvik-sdk-b4.zip . Note that we changed the name of the download from android-sdk to dalvik-sdk, as our port relies on Dalvik (which is available on Android devices) and not on a separate JVM. The latter would be possible as well, and some work has been done in this area, but unfortunately there is no open-source JVM that is close enough to be usable right now.

With dalvik-sdk-b4, and with the instructions at https://bitbucket.org/javafxports/android/wiki/Building%20and%20deploying%20JavaFX%20Applications, we reached a milestone. Most of the JavaFX 8 Ensemble applications are now working out of the box on Android devices. I've seen many reports from JavaFX developers demonstrating their applications on Android, which is very cool.

Next steps

I think we proved that there is room for JavaFX on Android devices. I know at least a few companies that are considering JavaFX partially base their decision on whether or not their application will run on Android and iOS. I think both RoboVM and our Android community effort show that it is very well possible to run JavaFX applications on mobile devices.

Going forward, there are a number of challenges that need to be addressed. Currently, only applications compiled with Java 7 can be deployed on Android. Lambdas, Streams and Defender Methods are not yet supported. Also, the tools need to improve. Currently, we provide a gradle script that generates an ant-project that allows your javafx application to be packaged into an .apk bundle, which can then be deployed on an Android device -- or, in the end, uploaded to the Play store. Integration with leading IDE's would be extremely helpful to developers.

At the same time, the main JavaFX development is no longer happening in the openjfx-8-graphics repository that we use as the upstream repository. A new repository is created, and this seems like a good moment to try to merge our changes back into the main repository. Clearly, there are a number of challenges we encounter, but I don't think there is a real show-stopper. For example, we are investigating RetroLambda for allowing the use of Lambda code.

The JavaFX port for Android has been an interesting project so far, and I'm really excited to see videos and screenshots from people who got their applications working on Android. Keep them coming!

written on 20 Jan 2014 13:49.

8 comments

Author: Tom
Date: 20 Jan 2014 14:22
permalink

Keep up the good work and momentum. Your effort is highly appreciated!

Author: me
Date: 27 Jan 2014 16:50
permalink

JavaFX needs to be published as part of OpenJDK. Unless it is preinstalled by default on all Linux systems - and OpenJDK is the only way to achieve this - I cannot use it: my users won't have it.

Author: sajal
Date: 28 Jan 2014 13:45
permalink

Is it true that JavaFX is not officially supported on windows 8.1 tablets/mobile devices?

Author: Julian
Date: 28 Jan 2014 13:50
permalink

What about Androids upcoming main JVM - ART? Is there going to be a port for this vm too?

Author: Daniel Zimmermann
Date: 28 Jan 2014 17:42
permalink

Hi. Before I start asking questions just let me say how grateful I am, that you did all the hard stuf! But (of course there is one, eh?): I just tried to compile a project of mine and run into an issue, telling me, that my latest paltform does not contain the "android.bat" file. That is - in fact - correct, since it is situated in the Android SDKs tools directory. Would it be enough just to copy it into the platforms directory, or do I need to modify the gradle.build file to point to the tools directory instead? Thanks in advance, Daniel

Author: Daniel Zimmermann
Date: 29 Jan 2014 09:04
permalink

I looked into the issue and it turned out, that the "gradle.build" was looking for the "android.bat" in a totally wrong place - the working dir. I modified the task "androidCreateProject" and changed "if (os.contains("windows")) {executable 'android.bat' }" to "if (os.contains("windows")) {executable conf.ext.sdk +'/tools/android.bat' }". The gradle build was succesful afterwards. Unfortunatly the ant build was not :-) I guess I have to keep on digging ;-)

Author: Prashant Agrawal
Date: 29 Jan 2014 09:44
permalink

Hello Daniel Zimmermann, i went through your steps and now able to build through gradle. this process creates an android project along with few ANT build files, but while running "ant build" getting issue as below and all the folder which created during command execution are empty. D:\JavaFxSampleRnD\jfxSampleTest\MainApp1>ant build Buildfile: D:\JavaFxSampleRnD\jfxSampleTest\MainApp1\build.xml BUILD FAILED Target "build" does not exist in the project "MainApp". Total time: 0 seconds D:\JavaFxSampleRnD\jfxSampleTest\MainApp1>

Author: Prashant Agrawal
Date: 29 Jan 2014 12:27
permalink

Hello Daniel Zimmermann, Some How i managed it and try to run "ant build" command and getting outofmemmoryException, please find below log. D:\JavaFxSampleRnD\jfxSampleTest\MainApp1>ant debug Buildfile: D:\JavaFxSampleRnD\jfxSampleTest\MainApp1\build.xml -set-mode-check: -set-debug-files: -check-env: [checkenv] Android SDK Tools Revision 22.3.0 [checkenv] Installed at E:\NC826\Software\adt-bundle-windows-x86-20131030\adt-bundle-windows-x86-20131030\sdk -setup: [echo] Project Name: MainApp [gettype] Project Type: Application -set-debug-mode: -debug-obfuscation-check: -init-env: -check-uptodate: -install-jfxrt: -install-application: -pre-build: -build-setup: [getbuildtools] Using latest Build Tools: 19.0.0 [echo] Resolving Build Target for MainApp... [gettarget] Project Target: Android 4.4 [gettarget] API level: 19 [gettarget] WARNING: No minSdkVersion value set. Application will install on all Android versions. [echo] ---------- [echo] Creating output directories if needed... [mkdir] Created dir: D:\JavaFxSampleRnD\jfxSampleTest\MainApp1\bin\rsObj [mkdir] Created dir: D:\JavaFxSampleRnD\jfxSampleTest\MainApp1\bin\rsLibs [echo] ---------- [echo] Resolving Dependencies for MainApp... [dependency] Library dependencies: [dependency] No Libraries [dependency] [dependency] ------------------ [echo] ---------- [echo] Building Libraries with 'debug'... [subant] No sub-builds to iterate on -code-gen: [mergemanifest] Found Deleted Target File [mergemanifest] Merging AndroidManifest files into one. [mergemanifest] Manifest merger disabled. Using project manifest only. [echo] Handling aidl files... [aidl] No AIDL files to compile. [echo] ---------- [echo] Handling RenderScript files... [echo] ---------- [echo] Handling Resources... [aapt] Found Deleted Target File [aapt] Generating resource IDs... [echo] ---------- [echo] Handling BuildConfig class... [buildconfig] Generating BuildConfig class. -pre-compile: -compile: [javac] Compiling 2 source files to D:\JavaFxSampleRnD\jfxSampleTest\MainApp1\bin\classes -post-compile: -obfuscate: -dex: [exec] warning: Ignoring InnerClasses attribute for an anonymous inner class [exec] (javax.activation.DataHandler$1) that doesn't come with an [exec] associated EnclosingMethod attribute. This class was probably produced by a [exec] compiler that did not target the modern .class file format. The recommended [exec] solution is to recompile the class from source, using an up-to-date compiler [exec] and without specifying any "-target" type options. The consequence of ignoring [exec] this warning is that reflective operations on this class will incorrectly [exec] indicate that it is *not* an inner class. [exec] warning: Ignoring InnerClasses attribute for an anonymous inner class [exec] (javax.activation.SecuritySupport$1) that doesn't come with an [exec] associated EnclosingMethod attribute. This class was probably produced by a [exec] compiler that did not target the modern .class file format. The recommended [exec] solution is to recompile the class from source, using an up-to-date compiler [exec] and without specifying any "-target" type options. The consequence of ignoring [exec] this warning is that reflective operations on this class will incorrectly [exec] indicate that it is *not* an inner class. [exec] warning: Ignoring InnerClasses attribute for an anonymous inner class [exec] (javax.activation.SecuritySupport$2) that doesn't come with an [exec] associated EnclosingMethod attribute. This class was probably produced by a [exec] compiler that did not target the modern .class file format. The recommended [exec] solution is to recompile the class from source, using an up-to-date compiler [exec] and without specifying any "-target" type options. The consequence of ignoring [exec] this warning is that reflective operations on this class will incorrectly [exec] indicate that it is *not* an inner class. [exec] warning: Ignoring InnerClasses attribute for an anonymous inner class [exec] (javax.activation.SecuritySupport$3) that doesn't come with an [exec] associated EnclosingMethod attribute. This class was probably produced by a [exec] compiler that did not target the modern .class file format. The recommended [exec] solution is to recompile the class from source, using an up-to-date compiler [exec] and without specifying any "-target" type options. The consequence of ignoring [exec] this warning is that reflective operations on this class will incorrectly [exec] indicate that it is *not* an inner class. [exec] warning: Ignoring InnerClasses attribute for an anonymous inner class [exec] (javax.activation.SecuritySupport$4) that doesn't come with an [exec] associated EnclosingMethod attribute. This class was probably produced by a [exec] compiler that did not target the modern .class file format. The recommended [exec] solution is to recompile the class from source, using an up-to-date compiler [exec] and without specifying any "-target" type options. The consequence of ignoring [exec] this warning is that reflective operations on this class will incorrectly [exec] indicate that it is *not* an inner class. [exec] warning: Ignoring InnerClasses attribute for an anonymous inner class [exec] (javax.activation.SecuritySupport$5) that doesn't come with an [exec] associated EnclosingMethod attribute. This class was probably produced by a [exec] compiler that did not target the modern .class file format. The recommended [exec] solution is to recompile the class from source, using an up-to-date compiler [exec] and without specifying any "-target" type options. The consequence of ignoring [exec] this warning is that reflective operations on this class will incorrectly [exec] indicate that it is *not* an inner class. [exec] warning: Ignoring InnerClasses attribute for an anonymous inner class [exec] (com.javafx.main.Main$1) that doesn't come with an [exec] associated EnclosingMethod attribute. This class was probably produced by a [exec] compiler that did not target the modern .class file format. The recommended [exec] solution is to recompile the class from source, using an up-to-date compiler [exec] and without specifying any "-target" type options. The consequence of ignoring [exec] this warning is that reflective operations on this class will incorrectly [exec] indicate that it is *not* an inner class. [exec] warning: Ignoring InnerClasses attribute for an anonymous inner class [exec] (com.javafx.main.Main$2) that doesn't come with an [exec] associated EnclosingMethod attribute. This class was probably produced by a [exec] compiler that did not target the modern .class file format. The recommended [exec] solution is to recompile the class from source, using an up-to-date compiler [exec] and without specifying any "-target" type options. The consequence of ignoring [exec] this warning is that reflective operations on this class will incorrectly [exec] indicate that it is *not* an inner class. [exec] [exec] UNEXPECTED TOP-LEVEL ERROR: [exec] java.lang.OutOfMemoryError: GC overhead limit exceeded [exec] at com.android.dx.ssa.RegisterMapper.map(RegisterMapper.java:49) [exec] at com.android.dx.ssa.NormalSsaInsn.mapSourceRegisters(NormalSsaInsn.java:48) [exec] at com.android.dx.ssa.SsaRenamer$BlockRenamer.visitNonMoveInsn(SsaRenamer.java:589) [exec] at com.android.dx.ssa.NormalSsaInsn.accept(NormalSsaInsn.java:206) [exec] at com.android.dx.ssa.SsaBasicBlock.forEachInsn(SsaBasicBlock.java:989) [exec] at com.android.dx.ssa.SsaRenamer$BlockRenamer.process(SsaRenamer.java:373) [exec] at com.android.dx.ssa.SsaRenamer$1.visitBlock(SsaRenamer.java:166) [exec] at com.android.dx.ssa.SsaMethod.forEachBlockDepthFirstDom(SsaMethod.java:812) [exec] at com.android.dx.ssa.SsaRenamer.run(SsaRenamer.java:163) [exec] at com.android.dx.ssa.SsaConverter.convertToSsaMethod(SsaConverter.java:52) [exec] at com.android.dx.ssa.Optimizer.optimize(Optimizer.java:98) [exec] at com.android.dx.ssa.Optimizer.optimize(Optimizer.java:72) [exec] at com.android.dx.dex.cf.CfTranslator.processMethods(CfTranslator.java:303) [exec] at com.android.dx.dex.cf.CfTranslator.translate0(CfTranslator.java:139) [exec] at com.android.dx.dex.cf.CfTranslator.translate(CfTranslator.java:94) [exec] at com.android.dx.command.dexer.Main.processClass(Main.java:682) [exec] at com.android.dx.command.dexer.Main.processFileBytes(Main.java:634) [exec] at com.android.dx.command.dexer.Main.access$600(Main.java:78) [exec] at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:572) [exec] at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284) [exec] at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166) [exec] at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144) [exec] at com.android.dx.command.dexer.Main.processOne(Main.java:596) [exec] at com.android.dx.command.dexer.Main.processAllFiles(Main.java:498) [exec] at com.android.dx.command.dexer.Main.runMonoDex(Main.java:264) [exec] at com.android.dx.command.dexer.Main.run(Main.java:230) [exec] at com.android.dx.command.dexer.Main.main(Main.java:199) [exec] at com.android.dx.command.Main.main(Main.java:103) BUILD FAILED D:\JavaFxSampleRnD\jfxSampleTest\MainApp1\build-extras.xml:39: The following error occurred while executing this line: D:\JavaFxSampleRnD\jfxSampleTest\MainApp1\build-extras.xml:40: The following error occurred while executing this line: D:\JavaFxSampleRnD\jfxSampleTest\MainApp1\build-extras.xml:50: The following error occurred while executing this line: D:\JavaFxSampleRnD\jfxSampleTest\MainApp1\build-extras.xml:26: exec returned: 3 Total time: 1 minute 21 seconds D:\JavaFxSampleRnD\jfxSampleTest\MainApp1>

Create comment