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

RESTEasy fails to build native image on latest 17 build of GraalVM Community and GraalVM #44877

Open
Christopher-Chianelli opened this issue Dec 2, 2024 · 3 comments
Labels
area/native-image kind/bug Something isn't working

Comments

@Christopher-Chianelli
Copy link
Contributor

Describe the bug

In our build matrix, we use the setup-graalvm action to get the latest GraalVM corresponding to the matrix's Java version:

  - uses: graalvm/setup-graalvm@v1
    with:
      java-version: ${{matrix.java-version}}
      distribution: 'graalvm-community'
      components: 'native-image'
      github-token: ${{ secrets.GITHUB_TOKEN }}
      cache: 'maven'

For Java 17, this fetches java 17.0.9-graalce (which can be installed with SDKMan: sdk install java 17.0.9-graalce)

RESTEasy uses Netty, which causes a build time error:

Error: Classes that should be initialized at run time got initialized during image building:
 io.netty.buffer.UnpooledUnsafeDirectByteBuf the class was requested to be initialized at run time (subtype of io.netty.buffer.AbstractReferenceCountedByteBuf). To see why io.netty.buffer.UnpooledUnsafeDirectByteBuf got initialized use --trace-class-initialization=io.netty.buffer.UnpooledUnsafeDirectByteBuf

The issue does not reproduce using latest Java 17 version of Mandrel (23.0.6.r17-mandrel).

Expected behavior

The REST sample project generated by code.quarkus.io native image builds successfully on the latest version of GraalVM for Java 17.

Actual behavior

This error appears during the native image build:

Error: Classes that should be initialized at run time got initialized during image building:
 io.netty.buffer.UnpooledUnsafeDirectByteBuf the class was requested to be initialized at run time (subtype of io.netty.buffer.AbstractReferenceCountedByteBuf). To see why io.netty.buffer.UnpooledUnsafeDirectByteBuf got initialized use --trace-class-initialization=io.netty.buffer.UnpooledUnsafeDirectByteBuf

How to Reproduce?

Reproducer: https://github.com/Christopher-Chianelli/issue-reproducer/tree/quarkus-native-17-failed-build
(App was generated from code.quarkus.io)

Output of uname -a or ver

Linux 6.11.10-300.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 23 00:51:20 UTC 2024 x86_64 GNU/Linux

Output of java -version

Java(TM) SE Runtime Environment Oracle GraalVM 17.0.12+8.1 (build 17.0.12+8-LTS-jvmci-23.0-b41)

Mandrel or GraalVM version (if different from Java)

No response

Quarkus version or git rev

3.17.2

Build tool (ie. output of mvnw --version or gradlew --version)

3.9.9

Additional information

No response

Copy link

quarkus-bot bot commented Dec 2, 2024

/cc @Karm (mandrel), @galderz (mandrel), @zakkak (mandrel,native-image)

@gsmet
Copy link
Member

gsmet commented Dec 2, 2024

Yeah, we had all sorts of weird issues with the Java 17 version of GraalVM. Even if you app is using Java 17, we recommend to use the Java 21 one.

We need to find a place to document it properly.

@zakkak
Copy link
Contributor

zakkak commented Dec 2, 2024

We need to find a place to document it properly.

Not exactly documented but Quarkus throws a warning like this:

[WARNING] [io.quarkus.deployment.pkg.steps.NativeImageBuildStep] You are using an older version of GraalVM or Mandrel : 23.0.5.0. Quarkus currently supports 23.1.0. Please upgrade to this version.

which admittedly also comes with some issues: a) uses the internal versioning instead of the JDK version so people might get confused, b) suggests upgrading to 23.1.0 which is not the latest 23.1 release.

Christopher-Chianelli added a commit to Christopher-Chianelli/timefold-solver that referenced this issue Dec 2, 2024
- Per quarkusio/quarkus#44877, GraalVM for
  Java 21 is recommended even for Java 17 projects, since GraalVM
  for Java 17 has weird issues with Quarkus

- Use quarkus.native.enabled since quarkus.package.type is deprecated

- Use org.graalvm.sdk:nativeimage instead of
  org.graalvm.sdk:graalvm-sdk per the recommendation in the logs
triceo pushed a commit to TimefoldAI/timefold-solver that referenced this issue Dec 2, 2024
- Per quarkusio/quarkus#44877, GraalVM for
  Java 21 is recommended even for Java 17 projects, since GraalVM
  for Java 17 has weird issues with Quarkus

- Use quarkus.native.enabled since quarkus.package.type is deprecated

- Use org.graalvm.sdk:nativeimage instead of
  org.graalvm.sdk:graalvm-sdk per the recommendation in the logs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/native-image kind/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants