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
Issue after upgrading from 4.3.8 to 4.4.0 #10768
Comments
hmm nothing seems to have changed with service loading in 4.4.x |
It looks like it is caused by the GraalVM version bump ( java.lang.UnsupportedClassVersionError: com/oracle/svm/core/jdk/resources/NativeImageResourceFileSystemProvider has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:467)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1217)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1228)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
at java.base/java.nio.file.spi.FileSystemProvider.loadInstalledProviders(FileSystemProvider.java:156)
at java.base/java.nio.file.spi.FileSystemProvider$1.run(FileSystemProvider.java:207)
at java.base/java.nio.file.spi.FileSystemProvider$1.run(FileSystemProvider.java:204)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(FileSystemProvider.java:204)
at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:526)
at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:400)
at io.micronaut.core.io.IOUtils.loadNestedJarUri(IOUtils.java:188)
at io.micronaut.core.io.IOUtils.resolvePath(IOUtils.java:165)
at io.micronaut.core.io.IOUtils.eachFile(IOUtils.java:98)
at io.micronaut.core.io.service.ServiceScanner.computeMicronautServiceTypeNames(ServiceScanner.java:106)
at io.micronaut.core.io.service.ServiceScanner$MicronautMetaServicesLoader.compute(ServiceScanner.java:296)
at java.base/java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:194)
at java.base/java.util.concurrent.ForkJoinTask.doExec$$$capture(ForkJoinTask.java:373)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java) This exception is swallowed, probably in IOUtils.eachFile(). When I downgrade Since Micronaut 4.x targets both Java 17 and Java 21 I suppose the 23.x version of the GraalVM components should be used. Furthermore it would be nice if the exception in IOUtils.eachFile() isn't swallowed as it makes finding the cause for this issue very hard. |
Expected Behavior
No response
Actual Behaviour
When trying to upgrade one of our major applications from Micronaut 4.3.8 to 4.4.0 (which includes the update from micronaut-core 4.3.14 to 4.4.3) we encounter the following exception when invoking a @MicronautTest:
It looks like Micronaut is loading
META-INF/micronaut/io.micronaut.inject.BeanDefinitionReference
from various .jar files and somehow initializes FileSystemProviders from different threads.What could be the cause for this error?
Steps To Reproduce
No response
Environment Information
Operating System:
MacOS Sonoma 14.4.1
JDK Version:
openjdk version "17.0.11" 2024-04-16
OpenJDK Runtime Environment Temurin-17.0.11+9 (build 17.0.11+9)
OpenJDK 64-Bit Server VM Temurin-17.0.11+9 (build 17.0.11+9, mixed mode)
Example Application
No response
Version
4.4.0
The text was updated successfully, but these errors were encountered: