[native-image] Windows with a swing application #1327
Comments
|
The problem here is that we still mark the whole JDK as build-time by default. The error message is misleading here--I am improving this case in a separate PR. Here you need to see what pulls those instances in the heap and mark that as run-time as well. We have another improvement that should show you the stack trace for when those got initialized. Till those PRs, you can attach with a debugger ( |
|
Anything new on this issue? I also run over it using the following code: import java.awt.BorderLayout; public class GUIlauncher { [guilauncher:11788] classlist: 4,565.27 ms |
|
Any update on this? I am also unable to build a swing application on linux using native-image and --no-fallback option. I can build using this: But when I run the executable: Any idea if Swing/AWT will be supported? |
|
I have the same problem. Unfortunately the compiled exe is not working alone. If you store the jar file in the same folder with the exe, it works, but without the jar could not be run… The program breaks with a AWT Thread.. If you compile the program, without reffering a swing window instance, then it could be compiled.. but running with a swing window, the system could not find the MAIN entrance point of the compiled exe.. Instantiating the swing window with a method, then ERRORS are coming all the time and all the way…. |
|
It seems that only console applications can be made .. But this is nonsense, mixture with NET Framework and Java.. appjav source code makking.. Would it be good if it worked, but how long would it take? I tried with 8u221, but unfortunately the end result is not a standalone executable .. The JAR is already an executable, then why is this all? |
|
I would suggest that if the EXE only work with JAR, put the resources and required codes for running the EXE into the JAR. |
|
I’m curious if there is a solution for this? I’m having the same problem with a relatively simple Swing application. |
|
If it helps to know it, here’s a simple test app: import java.awt.*;
import javax.swing.*;
public class JFrameExample {
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
displayJFrame();
}
});
}
static void displayJFrame() {
JFrame frame = new JFrame("My JFrame Example");
frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
frame.setPreferredSize(new Dimension(400, 200));
frame.pack();
frame.setVisible(true);
}
}And this is the result I get with the I’m just getting started with GraalVM, but I thought it would be great to create Swing apps as executables because they tend to start so slow, and consume a lot of RAM for even basic apps. Thanks! |
|
I am still out of luck... Devs, please help us! |
|
From the next release (already in master) you can use -H:+TraceClassInitialization to see how this Thread got initialized. You need to use When you come up with a working formula, we should merge this into the repo as this falls under the JDK. |
|
That will be great, I’m looking forward to it! |
|
I think once Graal is built with later JDKs that support for AWT will be included. The newer JDKs will most likely avoid using class init threads that are not supported by native-image. |
|
I tried again to build a "hello world" Swing jar with GraalVM CE 19.2.0 and got a huge amount of errors that I have no idea how to solve: I can build trivial .jars with native-image just fine. |
|
@pejovica assigning to you as the problem is in missing native implementations for security functions. |
|
I'm having the same problem as @Skhmt |
|
This is a major shortcoming. I'm unable to find any workaround to build even simplest swing applications. |
|
It would appear as though SubstrateVM doesn't support AWT. It's taken 5+ years to get to here. Adding AWT could take many more years. |
|
Don't think so, it is just not our priority. If you want, you would probably get it running in a matter of days. |
|
Probably the only thing needed is to create the JNI config. But what about threads started in ctors? I think that was another issue. |
|
You would need to define which classes should be marked with |
|
If there’s ever anything I can do as a Swing developer, just let me know, I’ll be glad to help. I know Swing/GUI apps aren’t as popular as web apps, but I still have customers that want them, and I’m always apologizing for the RAM they consume. If GraalVM could help with that issue, that would be awesome. |
|
You just start building an image and adding a flag by flag that fixes the problems. If you want to invest the time I will guide you through the process. |
|
Sure, I’ll be glad to do what I can. |
|
If it were possible to publish some detailed instructions, it would be great. |
|
The error messages should lead you through the problems, simply try to build your app and see what goes wrong. We can go through them one by one and fix everything that is unclear on the way. |
|
Before the next attempt, is there anyone here who has really been able to make it work? I mean, who has been able to make a 100% functional build. EDIT: Ok, partially functional? |
|
Did someone used the agent successfully on Windows? For me it never recorded anything for an SWT application. |
|
For simple SWT dialogs i used this: graalvm-swt-native-image also interesting: |
|
After building the Reflection config file, the resulting app generates a Headless exception. If I add -Djava.awt.headless=false to native-image it generates compile errors. |
|
If I remember correctly, that is caused by |
|
@pquiring do you have a repo for your example? Is there any example code for a minimal swing application with native-image? |
|
I am also awaiting Swing support with native-image. Hopefully this is possible soon. |
|
Even on the latest Graal dev build, still the same |
AWT is not yet supported on windows, but as a workaround you need to package awt.dll, java.dll, verify.dll and jvm.dll so they're available in the same directory as your exe. On top of that it will possibly require loads of jni config for awt (you could take a look at my PR draft if it helps #3079 ) The swing side I have no experience with. |
|
I have tested the newest current GraalVM I also tested JavaFX. The build finished, but the program failed at runtime with It's a pity; it would be great to have Java GUI binaries. |
|
JavaFX is an entirely different story and requires Gluon Substrate: https://docs.gluonhq.com/#_the_gluon_client_plugin_for_maven Sidenote, the newest current GraalVM would be 21.1, released 2 days ago. |
|
OK, my mistake, I have copied the wrong line. I have tested the examples against 21.1.0.r16-grl. Thanks for pointing to the Gluon Substrate, I will test it. |
|
Oh I remembered something else, with AWT and unix. I think native-image by default runs with TL;DL: try adding |
|
I tried to set the headless option to false and it passed. But later it failed with some linker error: |
|
Sorry, can't help you with that, it's a unix linker failure which I don't know anything about. |
|
With Graal 21.1 still getting errors. Used -H:+TraceNativeToolUsage to get more detailed reason for the failure. |
|
Some folks say they managed to get it to work, others wrote they did not. Would it be possible to add a simple "hello world" button via native-image + swing, as part of the official documentation, |
|
Doing that does suggest, that Scala + Swing = Native actually works, beyond Hello World. If not even that is consistent, I see it as detrimental to encourage people in the official documentation to use it. Do you agree? |
|
At this point, we are striving to support all libraries (given they are configured correctly). I don't see why we would treat Swing any different in terms of documentation. I think a blog post in this space would be great to show the process of using Swing with Native Image. Two interesting things here are the configuration experience with Swing, great startup time, and all the benefits that come with a native&standalone deliverable. |
|
It would be great if AWT and Swing would be supported by default (without the need to configure anything), because they are part of the JDK, not some external library. |
The problem with that is that awt is huge, and adding config for all of that probably means that a bunch config gets added when it isn't really required just because the calling class is reachable. AWT is a bit of a mess imo and once 1 thing is accidentally or intentionally required, it can cascade a lot. To give you an idea how much config is required: #3079 |
|
so for record, I was able to run the native image command for a simple swing app. Here is what I did Swing app Main class } I used the following coomands C:\graalvm-ce-java17-22.1.0\bin\java -agentlib:native-image-agent=config-output-dir=config -jar c:\Users\mis_p\OneDrive\Documentos\NetBeansProjects\SimplreSwing\target\SimplreSwing-1.0-SNAPSHOT-jar-with-dependencies.jar c:\graalvm-ce-java17-22.1.0\bin\native-image.cmd -jar c:\Users\mis_p\OneDrive\Documentos\NetBeansProjects\SimplreSwing\target\SimplreSwing-1.0-SNAPSHOT-jar-with-dependencies.jar test --initialize-at-build-time=sun.awt.Toolkit -Djava.awt.headless=false -H:ConfigurationFileDirectories=config Image was created and run without issues, but when I tried to add a look and feel it started failing. Had anyone else been able to add a look and feel? |
|
so for record, I was able to run the native image command for a simple swing app. Here is what I did Swing app Main class public static void main(String[] args) { } I used the following coomands C:\graalvm-ce-java17-22.1.0\bin\java -agentlib:native-image-agent=config-output-dir=config -jar c:\Users\mis_p\OneDrive\Documentos\NetBeansProjects\SimplreSwing\target\SimplreSwing-1.0-SNAPSHOT-jar-with-dependencies.jar c:\graalvm-ce-java17-22.1.0\bin\native-image.cmd -jar c:\Users\mis_p\OneDrive\Documentos\NetBeansProjects\SimplreSwing\target\SimplreSwing-1.0-SNAPSHOT-jar-with-dependencies.jar test --initialize-at-build-time=sun.awt.Toolkit -Djava.awt.headless=false -H:ConfigurationFileDirectories=config Image was created and run without issues, but when I tried to add a look and feel it started failing. Had anyone else been able to add a look and feel? |
|
@vjovanov I don't know if you're still involved in this or Graal, but something that might be useful is, I created an app with a simple jframe and was able to create the native image, I was able to add a panel and other containers, when adding a button or lable made the image fail not at build but when trying to run it, mostly the error points to Java.lang.reflect and fontmanager, but, when adding an awt button everything works. I wonder if there's a way to include the swing components at the image some how through config files or command line parameters, that should be enough to make it work |
|
@Snoopy137 in the long run yes. We strive to provide metadata for the JDK libraries as much as possible. However, due to the surface of the JDK we didn't have time to do it for all libraries. These kinds of issues are a good place for the community to contribute to the project. |
|
I was just investigating this myself and ran across a blog post from Bellsoft with instructions for building SwingSet2 on Windows, Linux and macOS. This uses their Graal-based Liberica Native Image Kit. Not sure whether it's just a repackaging of GraalVM community edition or whether they're actually adding some extra bits to it. Thought this might be helpful to others. |
|
build swing jfilechooser Component
|
|
Building an program using java2d for render tasks. This only happens when running the native executive file built by native-image, and if needed, the source code: here The output: |
and others
Running:
C:\graalvm-ce-19.0.0\bin\native-image.cmd -jar jPatcher.jar --no-fallbackI get the following:
So then I run:
C:\graalvm-ce-19.0.0\bin\native-image.cmd -jar jPatcher.jar --no-fallback --initialize-at-run-time=sun.awt.AWTAutoShutdown,sun.java2d.opengl.OGLRenderQueueNow I get:
What do I do now? It's saying to mark
sun.java2d.opengl.OGLRenderQueuefor initialization at run time when it's marked for initialization at build time and it says to mark it for initialization at build time when it's marked for initialization at run time.The text was updated successfully, but these errors were encountered: