-
Notifications
You must be signed in to change notification settings - Fork 322
Upgrade dependencies: Support Java 25's class file major version 69 #1440
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
Conversation
|
Maybe not directly related to this PR (also happend for #1334): |
103f090 to
0194182
Compare
codecholeric
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, thanks a lot of taking care of the house-keeping 🙂 I have two minor questions I'd be interested about
| testImplementation dependency.junit5Jupiter | ||
|
|
||
| testRuntimeOnly dependency.junit5VintageEngine | ||
| testRuntimeOnly dependency.junitPlatformLauncher |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I fully get this, why exactly does this break in archunit-3rd-party-test? AFAIS that module doesn't even have JUnit Jupiter tests, no? 🤔
Not sure we should really add this globally, even if it solves that symptom, in particular if it's only that one specific test module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've seen the
org.junit.platform.commons.JUnitException:OutputDirectoryProvidernot available; probably due to unaligned versions of thejunit-platform-engineandjunit-platform-launcherjars on the classpath/module path.
occur with the upgrade to JUnit 5.12 in other projects, too. I thought it was some kind of version conflict. Do you know what Gradle's useJUnitPlatform actually provides? Some Gradle upgrade notes mention:
If using JUnit 5, an explicit
runtimeOnlydependency onjunit-platform-launcheris required in addition to the existingimplementationdependency on the test engine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, and it turns out that not only archunit-3rd-party-test fails with this JUnitException – that just happened to be the first module where I saw the error. 🙄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I've dropped the misleading reference to archunit-3rd-party-test from the commit message.
If you prefer to understand the change with JUnit 5.12 better, we could also drop that update entirely from this PR, and have it in a separate one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah, if the docs say that you need that platform launcher dependency, then that's good enough for me 😉 Thanks a lot for the explanation!
| * Importing those would increase the memory footprint of the test tremendously, but not give an additional benefit for the test, | ||
| * so they are excluded for convenience. | ||
| */ | ||
| private static final ImportOption EXCLUDE_SUN_PACKAGES = l -> !l.contains("/sun/"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I still don't understand here, what has changed? The rt.jar archive of JDK 8 has been imported for many years, right? Do you know if the memory footprint of ArchUnit was simply smaller a couple of years ago? And if yes by how much? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In any case, since it always causes problems when we import rt.jar for JDK 8, I'd add this (and the comment) as part of importJavaBaseOrRtAndJUnitJarAndFilesOnTheClasspath() I think 🤔 Then you also wouldn't have to repeat it in every place where that method is used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand either where the change comes from, cf. #1446 (comment). I was wondering whether Gradle 8 might execute more tasks in parallel, such that the Github action runners might run out of memory more easily? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd add this (and the comment) as part of
importJavaBaseOrRtAndJUnitJarAndFilesOnTheClasspath()
There's also importJavaBase(), but it's certainly a good idea to keep the workaround down with those implementation details. 👍 I'll push an update.
5e3b0a2 to
c8140bb
Compare
…on 69 Signed-off-by: Manfred Hanke <[email protected]>
https://github.com/google/guava/releases/tag/v33.4.4 has - removed the dependency on JSR-305 [google/guava@04bf030] - migrated from Checker Framework annotations to (JSpecify)[https://jspecify.dev/] annotations [google/guava@2cc8c5e] - removed the dependency on Checker Framework annotations [google/guava@800b3d4] compare - https://repo1.maven.org/maven2/com/google/guava/guava/33.3.1-jre/guava-33.3.1-jre.pom - https://repo1.maven.org/maven2/com/google/guava/guava/33.4.8-jre/guava-33.4.8-jre.pom Signed-off-by: Manfred Hanke <[email protected]>
* org.apache.logging.log4j:log4j-{api,core,slf4j2-impl}
2.24.1 → 2.24.3
* org.assertj:assertj-{core,guava}
3.26.3 → 3.27.3
Signed-off-by: Manfred Hanke <[email protected]>
junit-jupiter = junit-jupiter-api + junit-jupiter-params + junit-jupiter-engine (runtime) Signed-off-by: Manfred Hanke <[email protected]>
Without the `junit-platform-launcher` dependency, `./gradlew test` fails with ``` org.junit.platform.commons.JUnitException: TestEngine with ID 'junit-jupiter' failed to discover tests at app//org.junit.platform.launcher.core.EngineDiscoveryOrchestrator.discoverEngineRoot(EngineDiscoveryOrchestrator.java:160) at app//org.junit.platform.launcher.core.EngineDiscoveryOrchestrator.discoverSafely(EngineDiscoveryOrchestrator.java:134) at app//org.junit.platform.launcher.core.EngineDiscoveryOrchestrator.discover(EngineDiscoveryOrchestrator.java:108) at app//org.junit.platform.launcher.core.EngineDiscoveryOrchestrator.discover(EngineDiscoveryOrchestrator.java:80) at app//org.junit.platform.launcher.core.DefaultLauncher.discover(DefaultLauncher.java:110) at app//org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:86) at app//org.junit.platform.launcher.core.DefaultLauncherSession$DelegatingLauncher.execute(DefaultLauncherSession.java:86) at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:124) at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:99) at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:94) at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:63) ... 16 more Caused by: org.junit.platform.commons.JUnitException: OutputDirectoryProvider not available; probably due to unaligned versions of the junit-platform-engine and junit-platform-launcher jars on the classpath/module path. at app//org.junit.platform.engine.EngineDiscoveryRequest.getOutputDirectoryProvider(EngineDiscoveryRequest.java:94) at app//org.junit.jupiter.engine.JupiterTestEngine.discover(JupiterTestEngine.java:67) at app//org.junit.platform.launcher.core.EngineDiscoveryOrchestrator.discoverEngineRoot(EngineDiscoveryOrchestrator.java:152) ... 26 more ``` Signed-off-by: Manfred Hanke <[email protected]>
resolves #1446 The CI build has recently often failed on `ubuntu` and `macos` with Java 8, due to `java.lang.OutOfMemoryError: GC overhead limit exceeded`. This is due to `ClassFileImporterSlowTest` importing the full classpath in some tests, which gives more than 20k classes on Java 8, which contains 7k classes in `com.sun` and 4k classes in `sun` packages that can easily be ignored. Signed-off-by: Manfred Hanke <[email protected]>
c8140bb to
7739b0b
Compare
|
thanks a lot for the update and digging into explanations! |
|
I hate to be the one asking for this, but could that change be ported back into 1.3? The sole ASM upgrade I mean. 😇 |
…on 69 resolves #1439 Signed-off-by: Manfred Hanke <[email protected]> (cherry picked from commit a475e03 / #1440)
resolves #1455 https://github.com/google/guava/releases/tag/v33.4.4 has - removed the dependency on JSR-305 [google/guava@04bf030] - migrated from Checker Framework annotations to (JSpecify)[https://jspecify.dev/] annotations [google/guava@2cc8c5e] - removed the dependency on Checker Framework annotations [google/guava@800b3d4] compare - https://repo1.maven.org/maven2/com/google/guava/guava/33.1.0-jre/guava-33.1.0-jre.pom - https://repo1.maven.org/maven2/com/google/guava/guava/33.4.8-jre/guava-33.4.8-jre.pom Signed-off-by: Manfred Hanke <[email protected]> (cherry picked from commit 93e489f / #1440)
|
@odrotbohm, the ASM and Guava update has been backported to ArchUnit 1.3.2, which is available on Maven Central. |
This PR upgrades
and for tests:
It reduces the memory footprint of
ClassFileImporterSlowTestby exluding classes fromsunpackages.