Android Port: Next Steps

[tomas.brandalik]

Hi Steve,
if you're using new Android studio then resolving dex max method limit 
issue won't be so easy. Android studio is based on gradle build system 
with android gradle plugin which doesn't allow modifying of dex task to 
generate more .dex files. You have to stick with good old ant for now.

-Tomas

On 01/03/2014 06: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
> 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
>>>>
>>>
>>