JavaFX-Bugs on GraalVM 19.3 (Java 11)

Thu Nov 21 19:38:25 UTC 2019

Well, GraalVM page says it's production ready.

By production ready I understand something way beyond "Hello, FX". Although, I would not expert perfection, since it's new technology.

The blue text also happens on my machine, running Linux. Probably a bug on graalvm, as it does not happen with standard jre.

Seems like a very hard to find bug.

Cheers.

________________________________
De: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> em nome de Johan Vos <johan.vos at gluonhq.com>
Enviado: quinta-feira, 21 de novembro de 2019 15:44
Para: Dirk Lemmermann <dlemmermann at gmail.com>
Cc: OpenJFX <openjfx-dev at openjdk.java.net>
Assunto: Re: JavaFX-Bugs on GraalVM 19.3 (Java 11)

As I said a number of times, this is ground-breaking new area, and still
work in progress. There is a reason we start with "Hello, FX" and not with
"Launch Apollo 11".
If you expect a 100,000 lines of code application to run without any issue
from day 1 on a new platform, yes, you might be disappointed. Although
reading the docs will probably making it not extremely hard. Worst case you
add all classes you have to the reflection list -- at the price of a big
footprint.

The native-image agent does a great job too, but that should be discussed
in the GraalVM slack or on the GraalVM issue tracker. (we actually used the
agent to come up with the required reflection list for the FX core classes
and it worked very well).

All components are written in Java though (OpenJFX, GraalVM, Substrate) and
open-source. So you're very welcome to make them better.

- Johan

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

> OK, I understand. But a real world application that already consists of
> say 100000 lines of code with tons of dependencies would require an
> enormous amount of work before the list of classes that need to be added to
> the reflections list is complete. This would be a trial and error approach.
> Launch …. “oh, that is missing” …. launch …. “oh that is missing” …. etc ….
> correct?
>
> Dirk
>
> On 21 Nov 2019, at 19:24, Johan Vos <johan.vos at gluonhq.com> wrote:
>
> 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
>> >>
>> >>
>>
>>
>