JavaFX 11 on Android

[Nir Lisker]

Hi Johan,

Thanks for the work. A couple of questions:


> I worked from the openjfx/develop repository and created a version that
> works on Android (will work on iOS soon).


I'm not very familiar with the state of mobile. Doesn't Android support
only up to Java 8 API? What happens if there is 'var' in the codebase, for
example?

4. Changes in common java classes (e.g. no System.Logger). Those are a
> problem.


If System.Logger is not available on Android an iOS, what is available
instead? jul or a native logger?

- Nir

On Thu, Oct 4, 2018 at 8:01 PM Johan Vos <johan.vos at gluonhq.com> wrote:

> Hi,
>
> I worked from the openjfx/develop repository and created a version that
> works on Android (will work on iOS soon).
> This required some changes, as we're running on top of the Android VM,
> which is not really Java (not even close).
> The longer-term goal is to run a JVM on Android as well, but that is not
> something to discuss in this topic.
>
> The changes I had to make are in this diff:
>
> https://github.com/javafxports/openjdk-jfx/compare/develop...johanvos:android
>
> There are a number of changes:
>
> 1. Changes in the Android specific files (e.g. FXDalvikEntity): those are
> mainly changes we did in the 8-tree, but that were never sent upstream. I
> think most of those can be upstreamed (after cleanup and review of course)
>
> 2. Changes in Monocle, mainly related to scale factor and HiDPI. Those can
> probably be upstreamed as well
>
> 3. Changes in the buildSrc/dalvik.gradle. Those are android-only, so can be
> upstreamed too.
>
> 4. Changes in common java classes (e.g. no System.Logger). Those are a
> problem.
>
> While I am in favour of leveraging the latest version of Java for doing
> JavaFX development, I do realise this breaks the Android port (not the iOS
> port, as we use a VM based on OpenJDK already there).
> While in theory we could deal with this using reflection (and this has been
> done in the 8-tree, e.g. for isIdeographic()), I don't think this is a good
> idea.
>
> My proposal would therefore be that I split the changes into
> Android/Dalvik/Monocle changes that do not affect any other platform, and
> create PR's for merging these changes in upstream. While my prototype is
> working (see https://twitter.com/johanvos/status/1047804607320260608)  I
> need to clean up the patches, and I suggest I create smaller PR's that are
> easier to digest.
>
> For the changes in the common classes, I think it's best to use a fork, or
> to patch the system at build time -- rather than polluting the main
> repository with reflection-based checks.
>
> Thoughts?
>
> - Johan
>