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.rushfo...@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 >
