JavaFX 11 on Android
John-Val Rose
johnvalrose at gmail.com
Thu Oct 4 20:32:59 UTC 2018
Johan,
I’m guessing that Gluon Mobile and GluonVM will run on Android with JavaFX 11 (eventually at least).
Is this correct?
Graciously,
John-Val Rose
Rosethorn Technology
> On 5 Oct 2018, at 06:00, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>
>
>> 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.
>
> This seems like a fine idea.
>
>> 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.
>
> As does this.
>
> -- Kevin
>
>
>> On 10/4/2018 10:01 AM, Johan Vos 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
>
More information about the openjfx-dev
mailing list