Android Port: Next Steps

[Johan Vos]

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
https://bitbucket.org/javafxports/android/issue/5/compiling-ensemble8-fails-because-of-dex

- Johan



2014/1/2 Stephen F Northover <steve.x.northover at oracle.com>

>  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>
>
>> 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.zipwith
>>> 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
>>>
>>
>>
>
>