Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AWT & Swing on Windows #3084

Open
pejovica opened this issue Dec 22, 2020 · 14 comments
Open

AWT & Swing on Windows #3084

pejovica opened this issue Dec 22, 2020 · 14 comments

Comments

@pejovica
Copy link
Member

pejovica commented Dec 22, 2020

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
Copy link
Contributor

kkriske commented Dec 24, 2020

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
Copy link
Member Author

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
Copy link

kirillp commented Dec 28, 2020

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
Copy link
Contributor

kkriske commented Dec 28, 2020

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
Copy link

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
Copy link

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
Copy link
Contributor

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
Copy link

@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
Copy link

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
Copy link

kirillp commented Apr 11, 2022

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
Copy link

gocursor commented Apr 11, 2022

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
Copy link

Barteks2x commented Jun 2, 2022

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
Copy link

kirillp commented Jun 3, 2022

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
Copy link

n1kub commented Mar 24, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants