Describe the bug
Building a native-image for the spring-web integration test with Graal VM 21.0 CE results in AWT classes getting pulled into the native image. This didn't happen with Graal VM 20.3 CE.
Expected behavior
No AWT classes, and, thus, native OpenJDK library dependencies should get pulled into the native image.
Actual behavior
AWT classes and dependencies get pulled in for a (seemingly) headless example app.
In an asynchronous discussion it was discovered that ImageIO usages in jaxb are legitimate. However, there should be some way to tell quarkus "this-is-a-headless-app-using-jaxb" and this, in turn, would remove/substitute ImageIO usages in jaxb and therefore not pull in AWT classes and native libs.
Describe the bug Building a native-image for the spring-web integration test with Graal VM 21.0 CE results in AWT classes getting pulled into the native image. This didn't happen with Graal VM 20.3 CE.
Expected behavior No AWT classes, and, thus, native OpenJDK library dependencies should get pulled into the native image.
Actual behavior AWT classes and dependencies get pulled in for a (seemingly) headless example app.
To Reproduce
Note
libawt_headless.a
andliblcms.a
etc. being added to the link command traced with-H:+TraceNativeToolUsage
.Environment (please complete the following information):
uname -a
orver
: Linux x86_64java -version
: 11.0.10+9Additional context See my comment about this in the resteasy ImageIO leak fix. Re-posting it here for posterity:
In an asynchronous discussion it was discovered that ImageIO usages in jaxb are legitimate. However, there should be some way to tell quarkus "this-is-a-headless-app-using-jaxb" and this, in turn, would remove/substitute ImageIO usages in jaxb and therefore not pull in AWT classes and native libs.
https://github.com/quarkusio/quarkus/issues/14972
$upstream:14972$