Skip to content

JUnit Jupiter breaks on Kotlin 1.9.0 / GraalVM native #6957

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

Open
sgammon opened this issue Jul 8, 2023 · 12 comments
Open

JUnit Jupiter breaks on Kotlin 1.9.0 / GraalVM native #6957

sgammon opened this issue Jul 8, 2023 · 12 comments
Assignees

Comments

@sgammon
Copy link

sgammon commented Jul 8, 2023

Describe the issue
Running JUnit Jupiter tests on Kotlin 1.9.0 fails when running under GraalVM (nativeTest via Gradle). See reproducer project.

Cross filed as:

The error:

kotlin.annotation.AnnotationRetention was unintentionally initialized at build time. kotlin.annotation.AnnotationRetention caused initialization of this class with the following trace:

This happens for classes:

  • kotlin.annotation.AnnotationRetention
  • kotlin.annotation.AnnotationTarget

Steps to reproduce the issue
Please include both build steps as well as run steps

  1. Generate a Micronaut project which uses Jupiter tests and GraalVM
  2. Upgrade from 1.8.22 to 1.9.0
  3. Run nativeTests, observe error

Describe GraalVM and your environment:

  • GraalVM version (latest snapshot builds can be found here), or commit id if built from source: EE 22.3.1, GraalVM 20
  • JDK major version: 19
  • OS: Ventura 13.4.1
  • Architecture: Apple M2

More details
This bug disappears when built against Kotlin 1.8.22. Changing the language version to 1.8 on SDK 1.9.0 yields no change.

(Log attached, too big for issue body)

@sgammon
Copy link
Author

sgammon commented Jul 8, 2023

error log: error-log-full.txt

@oubidar-Abderrahim
Copy link
Member

Hi, Thank you for reporting this issue, could you please specify the output of java -version for the GraalVM version used? also, did you try with the latest snapshot builds?

@sgammon
Copy link
Author

sgammon commented Jul 17, 2023

@oubidar-Abderrahim i've tried with EE 22.3.1, GraalVM 20. see below for both version outputs. i have not yet tried with snapshot builds

EE 22.3.1:

java version "19.0.2" 2023-01-17
Java(TM) SE Runtime Environment GraalVM EE 22.3.1 (build 19.0.2+7-jvmci-22.3-b11)
Java HotSpot(TM) 64-Bit Server VM GraalVM EE 22.3.1 (build 19.0.2+7-jvmci-22.3-b11, mixed mode, sharing)

Latest (GVM 20):

java version "20.0.1" 2023-04-18
Java(TM) SE Runtime Environment Oracle GraalVM 20.0.1+9.1 (build 20.0.1+9-jvmci-23.0-b12)
Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 20.0.1+9.1 (build 20.0.1+9-jvmci-23.0-b12, mixed mode, sharing)

@DarkAtra
Copy link

according to the Kotlin team this is caused by a new language feature called EnumEntries. All enum entries are initialized in a static initializer, e.g. during build-time.

They think this is a bug in Graal, what's your opinion on that and what do you recommend as a fix? Explicitly listing all Kotlin Enums via --initialize-at-build-time, as recommended by the Kotlin team, seems a bit strange to me.

@iseki0
Copy link

iseki0 commented Sep 1, 2023

It affects all library which dependent to kotlin-stdlib:1.9.0. Because in gradle the highest version will be chosen.

@DarkAtra
Copy link

hey @oubidar-Abderrahim, could you please comment on this issue? it currently blocks us from updating our projects to more recent kotlin versions and it would be great to know if there is something we're supposed to do or if it's considered a bug in graalvm or kotlin (in which case we would reach out to jetbrains again).

@oubidar-Abderrahim
Copy link
Member

oubidar-Abderrahim commented Nov 27, 2023

cc @dnestoro (GR 47593)

@oubidar-Abderrahim oubidar-Abderrahim removed their assignment Nov 27, 2023
@vjovanov
Copy link
Member

This will likely not be a problem with GraalVM versions after Java 21. The culprit class is not stored in the image heap so its initialization during JUnit initialization should not be a problem.

Note that with GraalVM 21 we need to add the --strict-image-heap flag to the native-image command line. Also, make sure to use the latest native-build-tools.

I'm looking forward to seeing if it works out.

@volkert-fastned
Copy link

volkert-fastned commented Dec 4, 2023

@vjovanov Thanks for the update. Can you maybe clarify what exactly you meant with "after Java 21"? Does that mean that we would we have to wait for Java 22? That would be unfortunate, not only since that will take quite a while longer, but also since Java 22 won't be an LTS version. Or perhaps you meant that it is expected to be fixed in a minor version update (Java 21.1.x)?

@vjovanov
Copy link
Member

vjovanov commented Dec 4, 2023

No need to wait for Java 22, it will work with the latest update of Java 21 with the flag --strict-image-heap.

@DarkAtra
Copy link

DarkAtra commented Dec 4, 2023

No need to wait for Java 22, it will work with the latest update of Java 21 with the flag --strict-image-heap.

would it be somehow possible to backport the fix to older versions? kotlin introduces support for java 21 in version 1.9.20 and there are other open issues that prevent me from updating to newer graal version (such as #7089)

@vjovanov
Copy link
Member

vjovanov commented Dec 6, 2023

Not possible unfortunately as this is a very involved change to the Native Image behavior.

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

7 participants