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