JavaFX 11 on Android

[Johan Vos]

Hi David,

Thanks for chiming in :)
see inline

Op do 4 okt. 2018 om 21:18 schreef David Grieve <david.grieve at oracle.com>:

> You just need Android Studio 3 for try-with-resources. See
> https://developer.android.com/studio/write/java8-support


Right, but there is Java 9 specific support for final variables:
https://blogs.oracle.com/darcy/more-concise-try-with-resources-statements-in-jdk-9
and
that doesn't work with 8 (we compile with --source 1.8 --target 1.8),
unless that is a compile time change only?


> I've never had a problem using java.util.logging with Android. Logging
> ends up in logcat.
>

That's why we are using java.util.logging indeed and that works fine. But
since 11, the JavaFX PlatformLogger uses the System.Logger which is not
available on Android.

- Johan



>
> On 10/4/18 2:45 PM, Nir Lisker wrote:
> >> But indeed, there are other things (e.g. try-resource with variable)
> that
> >> can not be used on Android. In general, there are too much restrictions,
> >> which is why we need a bundled Java 11 in the longer term.
>
> >
> > How does JavaFXPorts deal with this?
> >
> > We use java.util.logging for now.
> >
> >
> > That will require reverting the work of removing it [1] :) So yes, a fork
> > seems adequate for now and in the future we can re-evaluate the need for
> > j.u.l. (related: [2]).
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8195974
> > [2] https://bugs.openjdk.java.net/browse/JDK-8209036
> >
> > On Thu, Oct 4, 2018 at 9:13 PM Johan Vos <johan.vos at gluonhq.com> wrote:
> >
> >>
> >> On Thu, Oct 4, 2018 at 8:01 PM Nir Lisker <nlisker at gmail.com> wrote:
> >>
> >>> 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?
> >>>
> >> "var" will be ok as I think that has no influence at runtime?
> >> But indeed, there are other things (e.g. try-resource with variable)
> that
> >> can not be used on Android. In general, there are too much restrictions,
> >> which is why we need a bundled Java 11 in the longer term.
> >>
> >>
> >>> 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?
> >>>
> >> We use java.util.logging for now.
> >>
> >>
> >>> - 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
> >>>>
>
>