Which version of JAXP does Gradle implement?


Firstly: I am using Gradle 6.9, and IntelliJ is delegating all build operations to Gradle running on top of Java 11.

I am trying to debug a Gradle plugin I have written, and IntelliJ is failing to compile my test code because:

Unresolved reference: ACCESS_EXTERNAL_DTD
Unresolved reference: ACCESS_EXTERNAL_SCHEMA

This compiler error is bizarre! The plugin obviously compiles, builds and runs outside IntelliJ, and these XMLConstants values do exist! In fact, they’re mandatory as of JAXP 1.5 - which is ancient. However, it seems that the javax.xml.XMLConstants file inside gradle-api-6.9.jar somehow doesn’t contain them!?

There’s nothing in the JavaDocs to suggest I shouldn’t expect javax.xml.XMLConstants to have these fields for Java >= 7.

The javax.xml.XMLConstants inside gradle-api-7.0.jar is no better either.

I cannot explain this, but I do need XML generation to work inside my Gradle plugin. Can someone explain what is happening please? Has ProGuard been running amok?

Gradle requires Java >= 8, so having this javax.xml.XMLConstants anywhere on the classpath looks like a bug to me.


Edit: I have now reproduced the same problem outside of IntelliJ by running Gradle with Java 11, but configuring Java to use a Java 8 toolchain. I have previously been running Gradle with Java 8, which allows Gradle to find the JVM’s built-in XMLConstants class.

This sounds related to this issue: Generated gradle-api jar contains JRE classes and in old version which confuses Kotlin compiler · Issue #16147 · gradle/gradle · GitHub

Yes it does, except that I can now reproduce this without IntelliJ :slightly_frowning_face:. I am writing this plugin in Kotlin though.

This current situation is that I can compile my plugin when Gradle runs on Java 8, but not when Gradle runs on Java 11. I thought I might resolve this by declaring a compileOnly dependency on an artifact containing the JAXP 1.5 APIs, except I cannot find such a thing in Maven Central. I’m presumably supposed to be able to use the one included in the JDK these days.

I don’t understand the emphasized “without”.
My report has nothing to do with IntelliJ and I also explicitly say in the linked YouTrack issue that the compiling in Gradle is where it fails, completely independent from the IDE.

I followed the link to the issue in YouTrack, which ends by saying:

So the problem is in fact in the Kotlin IntelliJ plugin which places the JDK before any dependencies when analyzing a module (probably related to how sdkDependency is passed as firstDependency in AbstractResolverForProject), which does not correspond to how the code is compiled subsequently.

I don’t think I agree though.

Edit: In fact, I definitely disagree. I have created two trivial plugin projects: one in Java and the other in Kotlin:

public class JavaPlugin implements Plugin<Project> {
    public void apply(@Nonnull Project project) {
        project.getLogger().lifecycle("JAXP: {}, {}", ACCESS_EXTERNAL_DTD, ACCESS_EXTERNAL_SCHEMA);


class KotlinPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        project.logger.lifecycle("JAXP: {}, {}", ACCESS_EXTERNAL_DTD, ACCESS_EXTERNAL_SCHEMA)

Only the Java one compiles when Gradle runs on Java 11 :angry:. (Both compile when Gradle runs on Java 8 though.)

JetBrains has definitely filed your bug report under “Kotlin IntelliJ IDEA plugin” though :man_facepalming:.

They moved it there, yes.
Because the one who did that statement you quoted says that Kotlin and Java compiler behave the same.
If this is the case (which your example seems to contradict) then it is an IJ plugin issue that there the code shows green while the compiler flags it as red.
If it is not the case, then it seems to me to be a compiler issue while IJ is right.

And in the meantime, I have discovered that I can escape from between the Gradle rock and Kotlin hard-place by rewriting the affected classes in Java.

Go figure :stuck_out_tongue_winking_eye:.

1 Like