Android Port: Next Steps

[Stephen F Northover]

Hi Johan,

I looked and the kinds of changes that you are making in 
https://bitbucket.org/javafxports/android-graphics-rt 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 https://javafx-jira.kenai.com/browse/RT-35165 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 Eclipse.org.  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 
https://javafx-jira.kenai.com/browse/RT-35123 .  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 
> https://javafx-jira.kenai.com/browse/RT-35123
>
> 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 oracle.com 
> <mailto:steve.x.northover at oracle.com>>
>
>     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
>         https://bitbucket.org/javafxports/android/downloads/dalvik-sdk-b3.zip
>         with
>         instructions on how to build applications at
>         https://bitbucket.org/javafxports/android/wiki/Building%20and%20deploying%20JavaFX%20Applications
>
>         Building the runtime itself is explained at
>         https://bitbucket.org/javafxports/android/wiki/Building%20the%20JavaFX%20Android%20Runtime
>
>         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
>         https://bitbucket.org/javafxports/android-graphics-rt 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
>
>
>