I have a project I am trying to upgrade to Gradle 6.7. Currently, I’m on Gradle 6.3.
After I upgrade, I can’t build my project. It fails on the javadoc task with:
Caused by: java.lang.ClassCastException: class java.lang.String cannot be cast to class java.util.List (java.lang.String and java.util.List are in module java.base of loader 'bootstrap')
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Looks like a Gradle bug to me.
I downgraded to Java 11, but the problem remains.
Are you using the javadoc task directly in your build? Or are you invoking the javadoc task via a third party plugin? Can you include the javadoc configuration snippet from your
I don’t call the javadoc task directly, usually, it’s automatically called when I run
./gradlew build. There’s no plugin I am aware of that’s doing that.
Calling javadoc directly causes the same error.
I did not explicitly configure the javadoc task.
There might be something to do with the fact I use this plugin?
id 'org.javamodularity.moduleplugin' version '1.6.0'
You can see my current build file here if you think it helps: https://github.com/renatoathaydes/LogFX/blob/next/build.gradle
This branch uses Gradle 6.3. If I just change it to 6.7 and nothing else, it fails with this error.
Here’s the output when I run
./gradlew build --console=plain:
./gradlew build --console=plain
Task :buildSrc:compileJava UP-TO-DATE
Task :buildSrc:compileGroovy NO-SOURCE
Task :buildSrc:processResources NO-SOURCE
Task :buildSrc:classes UP-TO-DATE
Task :buildSrc:jar UP-TO-DATE
Task :buildSrc:assemble UP-TO-DATE
Task :buildSrc:compileTestJava UP-TO-DATE
Task :buildSrc:compileTestGroovy NO-SOURCE
Task :buildSrc:processTestResources NO-SOURCE
Task :buildSrc:testClasses UP-TO-DATE
Task :buildSrc:test UP-TO-DATE
Task :buildSrc:check UP-TO-DATE
Task :buildSrc:build UP-TO-DATE
Configure project :
Project : => ‘com.athaydes.logfx’ Java module
Task :compileJava UP-TO-DATE
Task :compileGroovy NO-SOURCE
Task :processResources UP-TO-DATE
Task :classes UP-TO-DATE
Task :jar UP-TO-DATE
Task :startScripts UP-TO-DATE
Task :distTar UP-TO-DATE
Task :distZip UP-TO-DATE
Task :fatJar UP-TO-DATE
Task :javadoc FAILED
FAILURE: Build failed with an exception.
- What went wrong:
Execution failed for task ‘:javadoc’.
class java.lang.String cannot be cast to class java.util.List (java.lang.String and java.util.List are in module java.base of loader ‘bootstrap’)
I think you’ve answered my question, you’re not including the javadoc task yourself, it’s being included via a third party plugin.
Its quite likely that the
org.javamodularity.moduleplugin is compiled against an old version of the
Javadoc task (and CoreJavadocOptions) but at runtime it’s running against a newer version where
CoreJavadocOptions.modulePath(...) has changed.
Is there a newer version of the
javamodularity plugin that you can try?
Yes, I was on 1.6.0 but they’ve already released 1.7.0.
Upgrading it fixed the problem. I had assumed the javadoc task was part of the Java Plugin, so did not suspect any other plugins… I guess you’re correct then, that they are calling it on behalf of my build
Well, in any case, the problem has gone away. Thanks for the help.
I had assumed the javadoc task was part of the Java Plugin
The javadoc task is a core task available on the classpath, but it’s not wired into the task graph by the java plugin. You need to do that yourself (or via a third party plugin)
Just a couple of pointers
There’s lots of logic in your build.gradle, I suggest putting the logic in custom tasks/plugins under
buildSrc and keeping
build.gradle purely declarative
I see a few tasks (eg deps and generateJavaSources) which don’t declare task inputs/outputs which means no up to date checks. The sign of a good build is to run a clean build then run a non-clean build (aka dirty build) after. Ideally the second build should do nothing, as every task should be up to date and have no work to do
@Lance yeah, I know but nearly all the logic is publishing and the jlink stuff… which I had to do like that because the existing plugins and functionality in Gradle are just not working well yet… I was hoping most of that was going to be temporary, but time goes by and it’s been there for a couple of years now … one day I will clean that all up and hopefully the plugins will have evolved to do the stuff that I needed (I did try some before but had lots of bugs)… I am hoping to get rid of that java.modularity plugin, because all I am doing there is standard stuff that Gradle should manage for me (I haven’t looked more closely yet, but l hope Gradle has better support for JPMS nowadays).