JavaFX-Bugs on GraalVM 19.3 (Java 11)

Thu Nov 21 22:45:36 UTC 2019

I have filed this issue as:
https://github.com/oracle/graal/issues/1867

This issue can be seen if you just use the GraalVM 19.3(11) in JIT mode
as well as with a native-image via --force-fallback.

When trying to create a real native-image of my application via the 
gluon client-plugin
I just get lots of errors which I still have to sort out. The samples 
all work (there
is a bug in one of the POMs though), so my system setup seems to be correct.
It is just for large apps where the build process freaks out.

--Michael

Am 21.11.19 um 21:36 schrieb Johan Vos:
> We're running pretty complex apps already, way beyond HelloFX.
> Startup time is amazing. GraalVM itself is already great.
>
> Tooling and configuration are the area where lots of work is still needed,
> and where Gluon Substrate is filling the gap. It still requires much more
> work, and documentation -- fully agree with that.
>
> The color-bug is an interesting one. Would you mind filing an issue at
> https://github.com/oracle/graal/issues/ ? I'll look into it, but it would
> be good to have it in the appropriate issue tracker so we can easily circle
> back to other developers in case it is relevant.
>
> - Johan
>
>
> Op do 21 nov. 2019 om 20:39 schreef Thiago Milczarek Sayao <
> thiago.sayao at clamed.com.br>:
>
>> 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
>>>>>>
>>>>>>
>>>>