nowinandroid
nowinandroid copied to clipboard
Hundreds of exceptions when running unit tests
Steps to repro:
./gradlew testDemoDebug
Expected
- Tests pass without any extra information being output to the screen
Actual
- Hundreds of the following stacktraces are shown:
java.lang.instrument.IllegalClassFormatException: Error while instrumenting sun/text/resources/cldr/ext/FormatData_en_001.
at org.jacoco.agent.rt.internal_3570298.CoverageTransformer.transform(CoverageTransformer.java:94)
at java.instrument/java.lang.instrument.ClassFileTransformer.transform(ClassFileTransformer.java:244)
at java.instrument/sun.instrument.TransformerManager.transform(TransformerManager.java:188)
at java.instrument/sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:610)
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1027)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1105)
at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:182)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:821)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:741)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:621)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:638)
at java.base/java.lang.Class.forName(Class.java:625)
at java.base/java.lang.Class.forName(Class.java:600)
at jdk.localedata/sun.util.resources.provider.LocaleDataProvider.loadResourceBundle(LocaleDataProvider.java:54)
at jdk.localedata/sun.util.resources.provider.LocaleDataProvider.getBundle(LocaleDataProvider.java:40)
at java.base/sun.util.resources.Bundles$2.run(Bundles.java:270)
at java.base/sun.util.resources.Bundles$2.run(Bundles.java:265)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
at java.base/sun.util.resources.Bundles.loadBundleFromProviders(Bundles.java:264)
at java.base/sun.util.resources.Bundles.findBundleOf(Bundles.java:201)
at java.base/sun.util.resources.Bundles.loadBundleOf(Bundles.java:145)
at java.base/sun.util.resources.Bundles.of(Bundles.java:106)
at java.base/sun.util.resources.LocaleData$1.run(LocaleData.java:185)
at java.base/sun.util.resources.LocaleData$1.run(LocaleData.java:182)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
at java.base/sun.util.resources.LocaleData.getBundle(LocaleData.java:182)
at java.base/sun.util.resources.LocaleData.getDateFormatData(LocaleData.java:145)
at java.base/java.text.DateFormatSymbols.initializeData(DateFormatSymbols.java:747)
at java.base/java.text.DateFormatSymbols.<init>(DateFormatSymbols.java:151)
at java.base/sun.util.locale.provider.DateFormatSymbolsProviderImpl.getInstance(DateFormatSymbolsProviderImpl.java:85)
at java.base/java.text.DateFormatSymbols.getProviderInstance(DateFormatSymbols.java:371)
at java.base/java.text.DateFormatSymbols.getInstanceRef(DateFormatSymbols.java:361)
at java.base/java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:626)
at java.base/java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:603)
at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.getLastResortErrorLogFile(SystemApplicationClassLoaderWorker.java:137)
at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:105)
at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:71)
at worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:69)
at worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:74)
Caused by: java.io.IOException: Error while instrumenting sun/text/resources/cldr/ext/FormatData_en_001.
at org.jacoco.agent.rt.internal_3570298.core.instr.Instrumenter.instrumentError(Instrumenter.java:160)
at org.jacoco.agent.rt.internal_3570298.core.instr.Instrumenter.instrument(Instrumenter.java:110)
at org.jacoco.agent.rt.internal_3570298.CoverageTransformer.transform(CoverageTransformer.java:92)
... 39 more
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 65
at org.jacoco.agent.rt.internal_3570298.asm.ClassReader.<init>(ClassReader.java:196)
at org.jacoco.agent.rt.internal_3570298.asm.ClassReader.<init>(ClassReader.java:177)
at org.jacoco.agent.rt.internal_3570298.asm.ClassReader.<init>(ClassReader.java:163)
at org.jacoco.agent.rt.internal_3570298.core.internal.instr.InstrSupport.classReaderFor(InstrSupport.java:280)
at org.jacoco.agent.rt.internal_3570298.core.instr.Instrumenter.instrument(Instrumenter.java:76)
at org.jacoco.agent.rt.internal_3570298.core.instr.Instrumenter.instrument(Instrumenter.java:108)
Possibly relevant extra information:
$java --version
openjdk 21.0.5 2024-10-15
OpenJDK Runtime Environment JBR-21.0.5+8-631.8-jcef (build 21.0.5+8-b631.8)
OpenJDK 64-Bit Server VM JBR-21.0.5+8-631.8-jcef (build 21.0.5+8-b631.8, mixed mode, sharing)
From the stack trace it looks related to Jacoco
Switching to JDK 17 solved this. Just in case it's useful for anyone else, I use https://sdkman.io/ so switching between JDK versions is as easy as:
sdk use java 17.0.12-jbr
We're using 0.8.7 of JaCoCo which is very old at this point, we should update to latest which supports running the latest JDKs.
I don't think asking everyone to use JDK 17 should be our solution here, there are good reasons to run the latest JDK versions:
https://dev.to/cdsap/nowinandroid-builds-with-gradle-85-and-jdk-21-7fp
I'd suggest adopting toolchains. I think AGP can still be problematic.
Is that this https://github.com/android/nowinandroid/pull/1392?
For this issue specifically, we should just update JaCoCo - adopting a toolchain to force the JDK being used to 17 would hide these errors, but it would come back if we update the JDK being used at some point in the future. Whether or not to use toolchains is a separate issue.
For this issue specifically, we should just update JaCoCo - adopting a toolchain to force the JDK being used to 17 would hide these errors, but it would come back if we update the JDK being used at some point in the future. Whether or not to use toolchains is a separate issue.
It's available on 0.8.12
- JaCoCo now officially supports Java 22
Oh, we're already on that version since 0dd998765ced3cf8234df3dd3ad3f11a05fce034 from #1699
This can be closed as fixed then!