JavaFX-Bugs on GraalVM 19.3 (Java 11)

Michael Paus mp at
Thu Nov 21 22:45:36 UTC 2019

I have filed this issue as:

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.


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
> ? 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>:
>> 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> em nome de Johan
>> Vos <johan.vos at>
>> Enviado: quinta-feira, 21 de novembro de 2019 15:44
>> Para: Dirk Lemmermann <dlemmermann at>
>> Cc: OpenJFX <openjfx-dev at>
>> 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>
>> 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> wrote:
>>> Please file issues if you run into them:
>>> * JavaFX related:
>>> * GraalVM related:
>>> * Substrate related:
>>> 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
>> and
>>> see the code in e.g.
>> how
>>> this can be done with Substrate.
>>> - Johan
>>> On Thu, Nov 21, 2019 at 6:30 PM Dirk Lemmermann <dlemmermann at>
>>> 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> 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]
>>>>> [2]
>>>>> [3]
>>>>> [4]
>>>>> On Wed, Nov 20, 2019 at 10:22 PM Michael Paus <mp at> 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

More information about the openjfx-dev mailing list