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-boun...@openjdk.java.net> em nome de Johan
Vos <johan....@gluonhq.com>
Enviado: quinta-feira, 21 de novembro de 2019 15:44
Para: Dirk Lemmermann <dlemmerm...@gmail.com>
Cc: OpenJFX <openjfx-dev@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 <dlemmerm...@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....@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 <dlemmerm...@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....@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 <m...@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
