JDK17 broken test scanning #1717
Comments
|
A workaround is to use test filtering, filter.includeTestsMatching '*Test*'I'm unsure if this is a Gradle problem (7.3-nightly also fails), so feel free to close if so. |
|
@ben-manes I tried reproducing this issue locally by cloning caffeine, checking out the |
|
oh, sorry. I should have offered reproducer steps. The toolchain defaults to JDK 11, which was added after a user was confused when running against the wrong jdk version. You can switch using java.toolchain.languageVersion = JavaLanguageVersion.of(System.env.'JAVA_VERSION' ?: 11)Verified locally |
|
Attached is a minimal project that demonstrates this failure. |
|
I'm not sure when Marc (or anyone else who helps out with JUnit) will find cycles to track this down, but I did want to point out that JUnit 4.x doesn't come bundled with a classpath scanning or other test-discovery code. This might be an issue with Gradle or a Gradle plugin. |
|
yep, let me know if you want me to open it on the Gradle side instead. |
|
Yes, I suggest filing a bug against Gradle. You may want to first review gradle/gradle#16857 Note that the JUnit 5 does have code for class discovery, so the OOO you are experiencing when you use JUnit 5 with the vintage engine could be a JUnit issue, so you might want to file a separate bug at https://github.com/junit-team/junit5/issues |
|
Thanks @kcooney and @marcphilipp. Closing in favor of gradle/gradle#18465 |
|
I'll try to reproduce the OOME on JUnit5 after Gradle has official JDK17 support, just to avoid the noise if not your team's responsibility. |
|
HEY I still have the same problem i got this failures : |
|
@AbdelELZ that looks like a different bug. Please file a new issue with a full stack trace and steps to reproduce. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When running a JDK11-based project on JDK17, it fails with odd messages like below. This project primarily uses TestNG but has some JUnit tests for external tooling, e.g. to leverage Guava's collection tests, osgi testing, and similar. Generally these tests can live together and automagic scanning picks up what is appropriate.
In the stacktrace below,
CacheSpecis a custom TestNG annotation to influence generation of parameterized test arguments. The nested classLoaderis an enum for the argument options, e.g.@CacheSpec(removalListener = MOCKITO). For some reason only on JDK17 does the junit runner try to instantiate the enum as if a regular class.Full logs using 4.13.2
Switching to JUnit 5 with the vintage engine fails after 6 minutes with OOME before running the tests.
The text was updated successfully, but these errors were encountered: