(Unknown Source)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at org.gradle.internal.instantiation.generator.AsmBackedClassGenerator$InvokeConstructorStrategy.newInstance(AsmBackedClassGenerator.java:1948)
at org.gradle.internal.instantiation.generator.AbstractClassGenerator$GeneratedClassImpl$GeneratedConstructorImpl.lambda$newInstance$0(AbstractClassGenerator.java:510)
at org.gradle.internal.deprecation.DeprecationLogger$4.create(DeprecationLogger.java:295)
at org.gradle.internal.deprecation.DeprecationLogger.whileDisabledThrowing(DeprecationLogger.java:273)
at org.gradle.internal.instantiation.generator.AbstractClassGenerator$GeneratedClassImpl$GeneratedConstructorImpl.newInstance(AbstractClassGenerator.java:509)
at org.gradle.internal.instantiation.generator.DependencyInjectingInstantiator.doCreate(DependencyInjectingInstantiator.java:64)
... 94 more
Caused by: java.lang.ClassCastException: class jdk.internal.loader.ClassLoaders$PlatformClassLoader cannot be cast to class java.net.URLClassLoader (jdk.internal.loader.ClassLoaders$PlatformClassLoader and java.net.URLClassLoader are in module java.base of loader 'bootstrap')
at org.gradle.initialization.DefaultJdkToolsInitializer.initializeJdkTools(DefaultJdkToolsInitializer.java:41)
at org.gradle.api.internal.tasks.CompileServices$GradleScopeCompileServices.configure(CompileServices.java:55)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:125)
at org.gradle.internal.service.ReflectionBasedServiceMethod.invoke(ReflectionBasedServiceMethod.java:34)
at org.gradle.internal.service.DefaultServiceRegistry.applyConfigureMethod(DefaultServiceRegistry.java:203)
... 113 more
* Get more help at https://help.gradle.org
BUILD FAILED in 3s
I’m using Java 17 and gradle 8, i feel it’s a gradle-wrapper error, but not sure…
Any help is appreciated.
Ok, thanks.
So I had a closer look at the stacktrace you posted.
But that is pretty much confusing.
In Java 9 there were many changes.
One change was, that
PlatformClassLoader
does not implement
URLClassLoader
anymore (it is an internal class anyway). Your stacktrace says that Gradle is trying nevertheless to cast the former to the latter and of course fails.
Another change in Java 9 was, that it does not contain a
tools.jar
anymore.
Actually Gradle checks whether a
tools.jar
is available in the JDK used to run Gradle and if it finds one, only then does that cast to inject the
tools.jar
into the system class loader.
So the code that fails for you should not actually run, as
tools.jar
is not present on a Java 17.
Does your Java installation that is used there come with a
tools.jar
in the
lib
folder?
Or did you put a
tools.jar
there yourself?
Either way, you should probably open a bug report for Gradle to handle the case that there is a
tools.jar
found but the class loader not being of the correct type more gracefully.
OMG Björn! You are an absolute legend!!! Yes it was the tools.jar that was causing the error, actually I was running the whole thing on my work laptop, and intelliJ was given preinstalled for us, it was probably some old version, and you know like, after spring boot 3 you are only allowed to use java 17 right… so i was using java 17, but on intelliJ i used to get the error that tools.jar is missing, so i had added that in the jdk. It worked for maven built projects, but gradle i guess got mad. But honestly, thank you so much, my senior at work with 20 years of experience said he couldn’t help me, even tho he had a look at my laptop, but you without even taking a look, just saw the error and gave possible solutions. ChatGpt was also dumbfounded when i pasted this error to it. I hope one day I become as good as you.
You should practically never add a
tools.jar
anywhere manually.
If you get a message that it is missing, that means what you use there needs a JDK of an older Java version.
Before Java 9, the
tools.jar
- which contained things like the Java compiler - were included in the JDK but not in the JRE.
Some tools that need the things from
tools.jar
checked for its existence and complained if it was missing, usually meaning you used a JRE instead of JDK.
If some tool complains about missing
tools.jar
with Java 9 or newer, it just means you need to use a newer version of that tool, or an older version of Java. Providing a
tools.jar
manually is not really the best idea, because it then also does not match version-wise.
Nevertheless you should open a bug report with Gradle to handle this situation more gracefully.
It should not fail to start up just because someone throws a file named
tools.jar
in there, or if it fails to start up, it should at least fail with a more meaningful message.
To begin with, it is Björn or Bjoern,
not
Bjorn.
Great that you reported it, you should also link it here for others to easily find it if they read this thread.
If you also want to fix it, that’s even better, if a PR exists, it is more likely it will get fixed. At
gradle/CONTRIBUTING.md at master · gradle/gradle · GitHub
you find a documentation about contributing.
