Improve AWT Support

[christianwimmer]

TL;DR

Improve AWT support to use dynamic linking of the AWT native code libraries. Generalize the dynamic linking approach, which is currently used only on Windows, to all platforms. Drop the current static linking approach used for Linux

Goals

The current support for AWT on Windows uses dynamic linking of the native code libraries: the unmodified shared libraries of the JDK are loaded dynamically at image run time using the regular JNI mechanism. The only "downside" of this approach is that the shared libraries need to be shipped together with the application executable.

On Linux, currently a static linking approach is used: the AWT native code is linked statically into the application. This approach has significant compatibility issues and would require changes to the native code for future JDK versions and to support additional platforms. It is therefore a goal to remove the static linking approach on Linux and switch to the dynamic linking. Once dynamic linking is working on Windows and Linux, adding support for MacOS will be not much additional work.

Non-goals

• We will remove the current static linking approach used for Linux. This approach can be considered a failed experiment because it is not maintainable and has no significant benefits over the dynamic linking approach.
• It is not a goal to provide a complete reflection and resource registration of all parts of AWT. Each application still needs to provide its own registrations, which can be collected using the tracing agent.

[anasmughal]

Thank you for slating this to a future release. Do we have any idea when it will be available?

Out product release depends on this.

Thanks.

[bflorat]

"The only "downside" of this approach is that the shared libraries need to be shipped together with the application executable." Could you please detail what you think of ?

As a packager, what will I be required to ship within my application ? provide libawt.so ? a full JRE (which would obviously defeat the goal of graalvm native image feature) ?

[kristofdho]

As a packager, what will I be required to ship within my application ? provide libawt.so ? a full JRE (which would obviously defeat the goal of graalvm native image feature) ?

I imagine this will work the same for unix as it currently works for Windows. An example of how my (cleaned up) target folder looks with a completed build:

The content of native-image.build_artifacts.txt:

[EXECUTABLE]
native-image.exe

[JDK_LIB]
awt.dll
fontmanager.dll
freetype.dll

[JDK_LIB_SHIM]
# Note that shim JDK libraries depend on this
# particular native image (including its name)
# and therefore cannot be used with others.
java.dll
jvm.dll

So everything you need will be available next to the executable. All you have to do is package it together.

[rubyFeedback]

All AWT/SWING related improvements are great. \o/

I wrote a bit of java swing code, and it works, and I also use jruby, where swing also works. Being able to use this via graalvm would be even better. Others reported success such as here: https://www.praj.in/posts/2021/compiling-swing-apps-ahead-of-time/ but he used inflection, and while I do understand a bit of java finally, I don't fully understand how to use inflection. The way I understand it is that we kind of have to tell the compiler (for a later point) what parts of the code are in use, reachable and should be optimized. If we don't "tell" the compiler that then the compiler may be unable to infer which code is more important and used - at the least this is roughly how I understood it so far.

I do not know the difference(s) between static linking and dynamic linking in regards to graalvm+Java. On Linux dynamic linking seems to be much more in use these days, but I would like to say that static linking may sometimes be useful. For instance, I compile busybox in a static manner. This is useful when other shared libraries are broken for the moment (such as some file is missing or so), so static linking does have a use case. This may be totally irrelevant for the issue here, but I wanted to mention it just in case. Requiring to put additional libraries into a binary sounds a bit cumbersome, so perhaps this is a disadvantage? I'd love if native-image could do this all for me so I don't have to worry about it. To me, even binary size per se would be less of an issue - I just want to have the aplication work ideally (I am even fine with simple AWT/Swing stuff, buttons, input-fields; the way I use Swing is mostly just for prototyping or quick GUIs that can then be used by non-computer savvy people. For me own use cases I don't need GUIs that much, I tend to use ruby a lot for scripting, so it is somewhat "automated" how I work with computers.) Anyway - hope that provided some use case, it's mostly just meant for more information to you folks. But I am glad the GUI world is not forgotten. Perhaps one day I can even get JavaFX or java-SWT via graalvm into one binary. \o/ On linux this works quite well, I got the statically compiled binary to work on the first or second attempt as-is, reading the official documentation. So when I can get it to work, others can get it to work too.

[pejovica]

AWT support for Linux has landed in master (see #6088). We now use dynamic linking as we do on Windows.

[Karm]

See https://github.com/oracle/graal/issues/6244

[nmammeri]

Please don't forget #5339