> > 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....@gluonhq.com> wrote: > > > On Thu, Oct 4, 2018 at 8:01 PM Nir Lisker <nlis...@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....@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 >>> >>
