AWT & Swing on Windows

[pejovica]

AWT & Swing are not currently supported on Windows. There are several aspects to adding this support, so the aim of this issue is to describe the overall approach. The actual work will be done under separate issues.

Linking with Native Libraries

When it comes to linking, we considered both options: static and dynamic. However, initial testing (which was fairly basic) has already revealed problems with static linking that can't be reasonably solved without modifying the JDK (e.g., it affects the static initialization order in such a way as to cause a segfault). On the other hand, dynamic linking allows us to reuse native libraries as they are.

Therefore, the plan is to add support for dynamic linking, as there are fewer unknowns.

Work is currently in progress: #3085

Swing

Native images currently have java.home set to null. This is problematic as the Swing code assumes the existence and layout of the java.home directory in order to load various configurations. So to avoid Swing substitutions, we need a real directory with the expected layout and content.

The plan is to set java.home to the directory from which the native image is executed.

Build Output

Both dynamic linking and Swing support imply that the output of a native image build will no longer be a single binary, but multiple binaries or even a whole directory.

The current plan is to put everything next to the built native image, which should be enough to enable proper functioning. Later, we could introduce some configurability and / or support to bundle everything into a zip archive.

Build Configuration

Currently, the use of native-image-agent (see documentation) is required even in the most trivial cases. And while this should be possible to improve, at this point it is difficult to say to what extent.

The rough idea is to provide AWT & Swing configurations out of the box where possible.

[kkriske]

For AWT support, are there plans in the long run to use static linking anyway?
And to avoid no longer having a single build artefact with the dynamic linking, could we instead store the dll as a resource in the image, and use the trick of writing it to a temp file and loading the extracted dll?

[pejovica]

For AWT support, are there plans in the long run to use static linking anyway?

No, we don't have such plans at the moment.

And to avoid no longer having a single build artefact with the dynamic linking, could we instead store the dll as a resource in the image, and use the trick of writing it to a temp file and loading the extracted dll?

I guess that could be an option too, we'll see.

[kirillp]

And to avoid no longer having a single build artefact with the dynamic linking, could we instead store the dll as a resource in the image, and use the trick of writing it to a temp file and loading the extracted dll?

for what reason we need this? this will slow down execution to allow virus scanning code to proceed newly created dll.
This is bad practice in general. What prevents you to bundle all with the main app ?

[kkriske]

This is bda practice in geleral. What prevents you to bundle all with the main app ?

For my use case, this is fine, but I've seen the pattern being used plenty before like javafx loading in all the api-ms-win-... dlls bundled with it. They do search for existing dlls first before extracting them but this likely won't be the case on the target systems. I merely suggested it as a possibility as it may be usefull if a single artefact is desired.

[pquiring]

Would it be possible to fix the static init order? Place @InitAfter and @InitBefore annotations on AWT classes and do static init thru some sort of table?

[pquiring]

The problem with these shim DLLs is they are app specific (ie: java.dll). So it wouldn't be possible to have multiple apps in the same folder.

[munishchouhan]

Please include this also
-Djava.home=$GRAALVM_HOME will load the "bin/jawt.dll" under java.home, is it possible to link it into the exe? same as the java.dll and jvm.dll
#3807 (comment)

[smallshen]

@mcraj017 Thanks for adding it, there is one more thing with the system resources, awt will laod
sun/datatransfer/resources/flavormap.properties
which will not be included in native-image
current workaround is copy the file from the jmod and add it to your own resources, and add it into the reousrce config

[gocursor]

Regards: "Build Output: Both dynamic linking and Swing support imply that the output of a native image build will no longer be a single binary, but multiple binaries or even a whole directory." => Please make a single binary by packing the needed dynamic libraries (DLLs, etc) as resources and unpack them at runtime during initialization. This is how GraalVM works with SWT where the SWT DLL is inside the EXE.

[kirillp]

Please take into consideration that

unpack them at runtime during initialization

could result in significant cost of system virus scanning software, blocking each app launching moment.
Unpacking dynamic libs on fly is not what most modern software is practicing.

[gocursor]

Unpacking dynamic libs on fly is not what most modern software is practicing.

This is true. But it is better to have a single binary (and unpack resources at runtime) than to have multiple files - which is similar to having JVM + application.jar. One of the benefits of GraalVM is the ability to produce a single binary...

[Barteks2x]

The way I use graalvm native image (currently with set) is to have a single executable that any user regardless of their skill level can run. With multiple files in a zip file, a lot of users would likely just double click on the executable while it's in the zip file and it would likely break. So for swing support to be of any use for mez it would have to be a single executable.

On Linux i can have an appimage and on Mac it's a DMG file that has everything bundled. There is no such thing on windows.
An installer is not an option because the application is an installer.

[kirillp]

One of the benefits of GraalVM is the ability to produce a single binary...

There is no such benefits or capabilities. GraalVM does AOT and store heap in the executable.
There is nothing about DLLs around it

There is no such thing on windows.

For Windows it is MSIX.
Please look at Conveyor Hydraulic packager or similar tools
There is no need to put all DLLs (like awt.dll, any other jni or 3rd party dlls) into exe and unpack them on the fly.

There are no such practices' on MAC or on Linux.

[n1kub]

What is the status of AWT support on Windows?
@mcraj017 could you provide any information?