JavaFX-Bugs on GraalVM 19.3 (Java 11)
dlemmermann at gmail.com
Thu Nov 21 18:29:35 UTC 2019
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?
> 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/ <http://bugs.openjdk.java.net/>
> * GraalVM related: https://github.com/oracle/graal/issues/ <https://github.com/oracle/graal/issues/>
> * Substrate related: https://github.com/gluonhq/substrate/issues <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 <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 <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 <mailto: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 <mailto:johan.vos at gluonhq.com>> wrote:
> > We have samples showing how to build and run JavaFX applications using
> > GraalVM. See our blog post  with samples .
> > 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 , which does most of this work:
> > Developers use a maven plugin  (gradle will be ready soon too) and this
> > is used in the samples .
> > 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
> > 
> > https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/ <https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/>
> >  https://github.com/gluonhq/client-samples <https://github.com/gluonhq/client-samples>
> >  https://github.com/gluonhq/substrate <https://github.com/gluonhq/substrate>
> >  https://github.com/gluonhq/client-maven-plugin <https://github.com/gluonhq/client-maven-plugin>
> > On Wed, Nov 20, 2019 at 10:22 PM Michael Paus <mp at jugs.org <mailto: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
More information about the openjfx-dev