Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement

Rony G. Flatscher Rony.Flatscher at wu.ac.at
Tue Apr 21 11:56:03 UTC 2020


Hi Michael,

thank you very much for sharing this link, which is very interesting!

Reading the limitation section is interesting and also reveals current assumptions of the GraalVM
developers that may not meet reality in full, hence making it a little bit cumbersome/difficult to
fully support it in use cases that they have not thought of or have not seen a need for (e.g. not
invoking finalize() because it got deprecated in Java 9, where the discussions that led to that
deprecation annotation were related to stated misuse of finalize() by Java programmers; but in those
discussions it also was undisputed that there are use cases where finalize() is actually useful and
important, e.g. in native bridges where finalize() gets used to clean-up Java proxies and their
non-Java peers; for that reason finalize() was not "deprecated for removal" and should only be
deployed, if there is a good reason; removing the invocation of finalize() is just a wrong decision
in that context with implications leading to scenarios where GraalVM might be considered to not be
usable). However, GraalVM is also a project in motion/development and as long as the ultimate goal
is to become fully compatible with Java hopes are that eventually the current
shortcomings/restrictions get solved/lifted (but some may prefer to wait until that has happened).

In any case it is impressive already that you guys have become able to use GraalVM for allowing
JavaFX to run on iOS and Android.

Again, thank you very much for your link which helps me a lot to assess that route (and to think
about solutions for current problems that may exist in GraalVM in supporting a dynamic language,
that needs reflective support and uses JNI).

---rony


On 20.04.2020 19:29, Michael Paus wrote:
> The Android/iOS work is based on GraalVMs Native Image which has some limitations.
> These can be found here: https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
> I stumbled over the problem with Method Handles when I tried to integrate some third-party
> software into it. (E.g. Log4J and NSMenuFX)(I had to abandon Log4J and fixed the problems in
> NSMenuFX.)
>
> Am 20.04.20 um 15:26 schrieb Rony G. Flatscher:
>> On 20.04.2020 15:06, Michael Paus wrote:
>>> This is deviating quite a bit from the original issue of this thread, isn't it?
>>>
>>> As a side note: MethodHandles are not supported by GraalVM native image
>>> and so this would probably collide with the attempts to get JavaFX running
>>> on Android/iOS.
>> Would you have some link where there would be a technical overview about how Java and JavaFX support
>> gets currently realized under Android/iOS? Also, how is reflection supposed to be carried out on
>> that platform, ie. is java.lang.reflect available?
>>
>> ---rony 



More information about the openjfx-dev mailing list