"Should not reach here" error compiling a Swing application #4072
Assignees
Labels
Comments
|
@dmclean652 thanks for reporting the issue, please share a reproducer. |
|
The error likely originates from the linker. -H:+TraceNativeToolUsage might help get more information about the linker invocation
|
|
As the original poster couldn't include their proprietary code, here is some simple Swing code that easily reproduces the reported problem (taken from a comment in an old issue: #1327): 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);
}
}Using the As mentioned by @petermz, adding the |
|
Thank you @chirontt . When I ran with -H:+TraceNativeToolUsage that was the exact error I received. |
|
@chirontt I tried the reproducer, but it builds and run successfully: |
|
I'm not sure what's different. I just performed the exact same test and still had the error. I tried several variants as well and they all behaved the same:
I have a slightly different Visual Studio 2019 version 14.29.30137.0 vs 19.28.29913. But I had an older version and updated today and both gave the same error. I don't have a full Visual Studio 2019, just the build tools. Are there any other build switches that may be helpful here? Any other parts of the build tools/environment that we can look at that may be different? |
|
@mcraj017 if you try it with the @dmclean652 try using the |
|
@chirontt thanks for the correction |
|
Using JDK11 I found:
Building with modulesResult of building with classpath onlyThis can be reproduced using the example code: public class JFrameExample {
public static void main(String[] args) {
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
} catch (Exception e) {
e.printStackTrace();
}
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);
}
} |
|
@dmclean652 Your above example code works fine for me. Using the Then just run the resulting native image:
which would display a simple JFrame on screen. |
|
@christianwimmer With: linkerInvocation.addNativeLinkerOption("/export:JDK_LoadSystemLibrary");
linkerInvocation.addNativeLinkerOption("/export:JNU_CallMethodByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_CallMethodByNameV");
linkerInvocation.addNativeLinkerOption("/export:JNU_CallStaticMethodByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_ClassString");
linkerInvocation.addNativeLinkerOption("/export:JNU_GetEnv");
linkerInvocation.addNativeLinkerOption("/export:JNU_GetFieldByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_GetStaticFieldByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_IsInstanceOfByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_NewObjectByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_NewStringPlatform");
linkerInvocation.addNativeLinkerOption("/export:JNU_SetFieldByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowArrayIndexOutOfBoundsException");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowIOException");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowIllegalArgumentException");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowInternalError");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowNullPointerException");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowOutOfMemoryError");
linkerInvocation.addNativeLinkerOption("/export:getEncodingFromLangID");
linkerInvocation.addNativeLinkerOption("/export:getJavaIDFromLangID");seems to fix the issue. Same list that gets passed to the java shim generation: Seems to do the trick on jdk 17 and doesn't break jdk 11, from a few simple test cases I ran. |
|
For anyone else looking for a workaround in the meantime, add a feature containing this in your codebase: @Override
public void beforeImageWrite(BeforeImageWriteAccess access) {
((FeatureImpl.BeforeImageWriteAccessImpl) access).registerLinkerInvocationTransformer(linkerInvocation -> {
linkerInvocation.addNativeLinkerOption("/export:JDK_LoadSystemLibrary");
linkerInvocation.addNativeLinkerOption("/export:JNU_CallMethodByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_CallMethodByNameV");
linkerInvocation.addNativeLinkerOption("/export:JNU_CallStaticMethodByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_ClassString");
linkerInvocation.addNativeLinkerOption("/export:JNU_GetEnv");
linkerInvocation.addNativeLinkerOption("/export:JNU_GetFieldByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_GetStaticFieldByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_IsInstanceOfByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_NewObjectByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_NewStringPlatform");
linkerInvocation.addNativeLinkerOption("/export:JNU_SetFieldByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowArrayIndexOutOfBoundsException");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowByName");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowIOException");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowIllegalArgumentException");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowInternalError");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowNullPointerException");
linkerInvocation.addNativeLinkerOption("/export:JNU_ThrowOutOfMemoryError");
linkerInvocation.addNativeLinkerOption("/export:getEncodingFromLangID");
linkerInvocation.addNativeLinkerOption("/export:getJavaIDFromLangID");
return linkerInvocation;
});
}or add them as |
@kkriske , If you can, can you be more specific on how we add this to a codebase or more preferably, how to pass these as cli options because I have not been able to find any useful documentation on this specific option ( Thanks |
|
@EpicGamer007 so your native-image command would become something like: after checking, it appears that |
Thank you so much :) |
|
@kkriske thanks a lot for your great workaround. This problem in Windows has stumped us since GraalVM 21.3.0 for JDK17, and still persists in 21.3.1 and in 22.0.0.2. Talking about 22.0.0.2, it has new link errors in Linux (in addition to in Windows which is fixed by your tip) for the JDK17 version, for the simple Swing code above. But I guess this new Linux problem will be for another issue thread... |
|
@pejovica can you please check what is going on? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the issue
I have a relatively small and straight forward Swing application that fails during native image compilation. I'm trying to build on Windows 10 and using Visual Studio 2017 Express. The error is the same if I use Visual Studio 2019 Express.
My command line is:
native-image --module-path . -m LogViewer/com.bkin.logviewer.gui.LogViewer
The error during the build is simply "Should not reach here" with no other detail. The java.dll is zero bytes when the build exists.
The code is proprietary, so I can't post it online. I'm mainly looking for extra information about why this is failing.
The GraalVM I'm using is: 21.3.0
JDK 17
Windows 10
AMD 64
Visual Studio 2017, v15.9
More details
The build output is:
Thank you for the help!
The text was updated successfully, but these errors were encountered: