JavaFX 11 on Android

[David Grieve]

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

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

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