Android Port: Next Steps

Stephen F Northover steve.x.northover at
Fri Jan 3 09:53:46 PST 2014

Any idea how it can be fixed using IntelliJ Android Studio?  Might be 
nice to run and debug on the device rather than debugging with println's.


On 2014-01-03 12:41 PM, Johan Vos wrote:
> Thanks Steve, that makes sense.
> I'll be back in the Android/JavaFX world in a few days, and will work 
> on this.
> About the dex-max-method-references: that is a known issue that is 
> fixed if you use the gradle script in android-tools. Explanation and 
> how-to-fix at 
> - Johan
> 2014/1/2 Stephen F Northover <steve.x.northover at 
> <mailto:steve.x.northover at>>
>     Hi Johan,
>     I looked and the kinds of changes that you are making in
> and I can
>     see that they fall into a number of different categories:
>     1) JDK8 Language Features
>     - work arounds for ObservableList default methods
>     - work arounds for the use of lambda (in test and example code)
>     - work arounds for the lack of final declarations (in test and
>     example code)
>     I have entered to
>     track the defender method problem.
>     Eventually, OpenJFX will embrace lambda expressions and it is
>     likely that iOS and Android will need to use RetroLambda.  When we
>     embrace lambda, there will be a JIRA that covers the work and you
>     an watch progress there.  In the meantime, you could look into
>     RetroLambda now and see if it will help you.  Since it works on
>     byte codes, you won't be able to step in the debugger because the
>     source won't match the executable.  This might not be an issue for
>     you.  ASIDE: I've attempted to build the code under Android Studio
>     and it runs out of method handles in dex during compile.  Any ideas?
>     In the case of final declarations, I think that there are so few
>     of them right now that we can just fix them as then sneak in.  You
>     will need to keep track of them as they happen.  Eventually, if
>     you earn commit rights, you can just fix them.
>     2) JDK8 Library (modules/compat/src)
>     - missing classes and annotations (such as FunctionalInterface)
>     - missing API in JDK7 classes (I thought I had gotten rid of these)
>     This code is not part of OpenJFX and should not be in the repo. 
>     Instead, you need to maintain and build the code somewhere else
>     and make a jar available as part of your build.  For example, when
>     OpenJFX is built, it gets the SWT jar from  You will
>     need to do something similar when OpenJFX for Android or iOS is built.
>     3) Android Build Files and Tools (android-tools and more)
>     - files like dalvik.gradle and shell scripts etc.
>     Some of this is being tracked by
> .  I suggest that
>     you enter JIRA for each part that you want moved over.  For
>     example, android-tools is not covered by this JIRA.
>     4) Android Specific Files (New and Changed files)
>     - src/dalvik
>     - android.h, LensApplication.c etc.
>     You will need to enter JIRA for these.  I'm not sure which changes
>     are needed and which are not.  FX embedded committers will need to
>     go over the changes as Android and Lens share the same code.
>     5) "Unnecessary Changes"
>     - these are mostly due to being out of sync with OpenJFX
>     - some of these are related to FunctionalInterface which you
>     should add to your JDK8 compat library
>     As more of your code moves over to OpenJFX, the list of changes
>     here will become zero.  I suggest that you browse all the changes
>     that you have and get rid of as many as you can while preparing
>     patches for OpenJFX.
>     Best of luck Johan!  Our goal is to bootstrap you port as quickly
>     as we can subject to the rules of the OpenJDK which we must
>     follow.  Please enter JIRA as necessary to track your work and we
>     can interact there.
>     Happy New Year!
>     Steve
>     On 2013-12-31 3:47 AM, Johan Vos wrote:
>>     Steve,
>>     The main issue is currently getting bootstrapped. If we want to
>>     build the Dalvik-runtime using open-jfx, we need a location on
>>     where to put the dalvik files. This is what I tried to describe
>>     in
>>     Please note that we're not really doing an Android port, but a
>>     Dalvik port. The (excellent) work done by Oracle in the past
>>     allowed for both using Dalvik as well as an Oracle-internal VM.
>>     There are no indications that the latter is ever going to fly, so
>>     I don't want to have an abstraction on top of {Dalvik, OracleVM}
>>     if only the first one exists. I do hope there will be other VM's
>>     (Oracle VM and more) later, as that will make it easier to have
>>     Java 8 and so on, but right now we have to stick with what we
>>     have (dalvik).
>>     Without these files, we can supply patches for existing files in
>>     open-jfx, but by no means we can build the runtime. I do
>>     understand it is not trivial to "add" a directory for the sake of
>>     a port, but then, a port is not trivial as well. I'm open to all
>>     suggestions.
>>     The longer we wait, however, with synchronizing the bitbucket
>>     repo with the open-jfx repo, the harder it gets. Right now, I
>>     have no other option than committing all changes in the bitbucket
>>     repo, as I need to be able to build a runtime. We had 419
>>     downloads of the runtime in 10 days, so clearly there are people
>>     interested in this.
>>     - Johan
>>     2013/12/20 Stephen F Northover <steve.x.northover at
>>     <mailto:steve.x.northover at>>
>>         Hi Johan,
>>         This is very good news.  We need to work together so that you
>>         are able to run OpenJFX unmodified.  This may not be
>>         practical for all sorts of reasons, but we need to seriously
>>         explore this and work towards this goal.  Please open JIRA
>>         for the various problems you are seeing and we can try to
>>         deal with them there and on this list.
>>         Thanks,
>>         Steve
>>         On 2013-12-20 12:56 PM, Johan Vos wrote:
>>             Hi,
>>             As you might know, 2 months ago I started a community
>>             effort for "porting"
>>             JavaFX to Android. Today, we released build 3 of the
>>             JavaFX Android
>>             runtime, which can be downloaded at
>>             with
>>             instructions on how to build applications at
>>             Building the runtime itself is explained at
>>             At this moment, most of the Ensemble suite runs on
>>             Android (positive
>>             reports starting with Android 3.x).
>>             The downloadable runtime is created using the bitbucket
>>             project at
>>             which is a fork of
>>             the openjfx-graphics-rt mirror on bitbucket. We merge
>>             often, so all changes
>>             made in openjfx-graphics should be in the Android runtime
>>             as well.
>>             There are a number of issues left:
>>             * touch map issues causing applications to crash if
>>             "touched too much". I
>>             created a JIRA ticket for this and will create another
>>             one (related, but
>>             not same cause) later.
>>             * Java 7 only. Currently, applications cannot make use of
>>             Java 8 features.
>>             Dalvik has no invokedynamic, so we can't do lambda's.
>>             * we just started, so there will be plenty of other bugs.
>>             We are also spending efforts in documentation and
>>             community interaction.
>>             The google group javafxandroid has a pretty active
>>             mailinglist. Build 2 of
>>             the runtime has been downloaded 291 times in 2 weeks, and
>>             build 3 has been
>>             downloaded 60 times since it was released a couple of
>>             hours ago. So there
>>             is definitely community interest and involvement.
>>             Clearly, there is involvement from Oracle as well. Most
>>             of the effort so
>>             far has been done by Tomas Brandalik and the Prague team.
>>             I was positively
>>             surprised to see the amount of native code that was
>>             already available for
>>             Android.
>>             After a few discussions, it has been agreed that we
>>             should try to
>>             synchronize as much as possible with the OpenJFX
>>             repositories, without
>>             jeopardizing the stability and performance of the main
>>             ports, and without
>>             running into legal trouble.
>>             I will run a diff on the current code versus the OpenJFX
>>             code, and I will
>>             try to create issues with patches for sending the changes
>>             back to OpenJFX.
>>             Not all changes can go back to OpenJFX. We had to add a
>>             number of classes
>>             that are missing on Dalvik and that are used by OpenJFX,
>>             and clearly we
>>             can't commit those in OpenJFX.
>>             We had to make a number of changes to JavaFX files as
>>             well, in order to
>>             make them compile with JDK 1.7. Most of these were about
>>             removing Function
>>             and adding implementations for the default interface
>>             methods on
>>             ObservableList.
>>             I have no clear opinion on how these changed files could
>>             somehow be used
>>             from within OpenJFX, but I'm very open to suggestions.
>>             Finally, keep in mind that this is a community effort.
>>             Nobody is paying for
>>             this, and it is done in our spare time. I'm doing my best
>>             to move forward
>>             as soon as I can, but I have other things to work on as
>>             well of course.
>>             However, the collaboration between the Java community and
>>             Oracle (mainly
>>             Tomas) has been great so far. It is in the interest of
>>             anyone working on or
>>             with Java to show the world that JavaFX runs on Android
>>             devices.
>>             - Johan

More information about the openjfx-dev mailing list