JavaFX-Bugs on GraalVM 19.3 (Java 11)

[Johan Vos]

Please file issues if you run into them:
* JavaFX related: http://bugs.openjdk.java.net/
* GraalVM related: https://github.com/oracle/graal/issues/
* Substrate related: https://github.com/gluonhq/substrate/issues

Keep in mind that with these new approaches come new docs, so make sure to
read them.

What you're saying sounds like you're not specifying the classes that are
accessed via Reflection. (Integer.parseInt for example). In the future,
agents will automatically add these for you, but for now you specify them
(e.g. via the client-maven-plugin by specifying it in the reflectionlist
property).
The GraalVM native-image docs are pretty good in explaining the reasons
behind this.
All reflection/JNI required by the JavaFX framework should be handled by
Substrate already. But if you use e.g. injection frameworks, you'll have to
add the classes. See
https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md and
see the code in e.g.
https://github.com/gluonhq/client-maven-plugin/blob/master/src/main/java/com/gluonhq/NativeBaseMojo.java#L95
how
this can be done with Substrate.

- Johan



On Thu, Nov 21, 2019 at 6:30 PM Dirk Lemmermann <dlemmermann at gmail.com>
wrote:

> After experimenting a lot today with the Gluon client plugin I must assume
> that currently not all of Java is supported via the substrate / GraalVM duo.
> For example I was unable to use the java.util.Preferences API. I also got
> an error that said Integer.parseInt() does not exist.
>
> Is that correct?
>
> > On 21 Nov 2019, at 18:26, Johan Vos <johan.vos at gluonhq.com> wrote:
> >
> > We have samples showing how to build and run JavaFX applications using
> > GraalVM. See our blog post [1] with samples [2].
> >
> > Keep in mind that JavaFX has some characteristics that make it
> non-trivial
> > to apply native-image out of the box (reflection/jni configuration,
> > platform-specific static libraries, including resources and bundles...).
> > This is why we created Gluon Substrate [3], which does most of this work:
> > Developers use a maven plugin [4] (gradle will be ready soon too) and
> this
> > is used in the samples [2].
> >
> > If you use GraalVM native-image without all the parameters that Gluon
> > Substrate adds, you will most likely create a "fallback-image" that still
> > require a JVM and some other resources to be available at runtime, and
> this
> > can give strange results. While I don't exclude JavaFX bugs will surface
> > using this approach, I think it's more likely you're seeing issues due to
> > this "mixed mode".
> >
> > - Johan
> >
> > [1]
> >
> https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/
> > [2] https://github.com/gluonhq/client-samples
> > [3]  https://github.com/gluonhq/substrate
> > [4] https://github.com/gluonhq/client-maven-plugin
> >
> > On Wed, Nov 20, 2019 at 10:22 PM Michael Paus <mp at jugs.org> wrote:
> >
> >> Hi,
> >>
> >> I would just like to know where JavaFX problems or bugs should be
> reported
> >> which are strictly related to running on the just released GraalVM 19.3
> >> with
> >> Java 11 support. Should they go into the regular JBS or should they be
> >> reported
> >> elsewhere?
> >>
> >> For example: I have observed that a large JavaFX application seems to
> work
> >> correctly at first but then suddenly all text on all controls turns
> >> white and
> >> white on white or light grey is not really readable anymore. I've never
> >> observed
> >> such a behaviour on any other VM before. There is also no error message
> or
> >> warning associated with this. It just happens.
> >>
> >> There even seem to be more issues when you try to use native-image.
> >>
> >> --Michael
> >>
> >>
>
>