JavaFX 11 on Android

Discussion:

Johan Vos

2018-10-04 17:01:08 UTC

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

Sverre Moe

2018-10-04 17:10:24 UTC

Permalink

That switch was made in Android N two years ago.
Maybe I am off base here. I haven't been fiddling around Android much for
some years.

/Sverre

Johan Vos

2018-10-04 18:07:20 UTC

Permalink

Post by Sverre Moe

That switch was made in Android N two years ago.
Maybe I am off base here. I haven't been fiddling around Android much for
some years.

They're pretty selective.
For some reason, they have some classes (e.g. sun.misc.SharedSecrets) that
are missing some methods.

Even if Android would be OpenJDK 8 (which it is not), that's not 11 and
it's impossible to predict when Google wants to move to 9/10/11

Nir Lisker

2018-10-04 18:00:48 UTC

Permalink

Hi Johan,

Post by Johan Vos
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?

4. Changes in common java classes (e.g. no System.Logger). Those are a

Post by Johan Vos
problem.

If System.Logger is not available on Android an iOS, what is available
instead? jul or a native logger?

- Nir

Post by Johan Vos
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.
https://github.com/javafxports/openjdk-jfx/compare/develop...johanvos:android
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

Johan Vos

2018-10-04 18:13:26 UTC

Permalink

Post by Nir Lisker
Hi Johan,

Post by Johan Vos
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.

Post by Nir Lisker
4. Changes in common java classes (e.g. no System.Logger). Those are a

Post by Johan Vos
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.

Post by Nir Lisker
- Nir

Nir Lisker

2018-10-04 18:45:43 UTC

Permalink

Post by Johan Vos
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

Post by Johan Vos

Post by Nir Lisker
Hi Johan,

Post by Johan Vos
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?

Post by Nir Lisker
4. Changes in common java classes (e.g. no System.Logger). Those are a

Post by Johan Vos
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.

Post by Nir Lisker
- Nir

David Grieve

2018-10-04 19:17:54 UTC

Permalink

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.