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.XMLConstantsanywhere on the classpath looks like a bug to me.
Cheers,
Chris
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.
Yes it does, except that I can now reproduce this without IntelliJ . 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 firstDependencyin 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> {
@Override
public void apply(@Nonnull Project project) {
project.getLogger().lifecycle("JAXP: {}, {}", ACCESS_EXTERNAL_DTD, ACCESS_EXTERNAL_SCHEMA);
}
}
vs
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 . (Both compile when Gradle runs on Java 8 though.)
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.
. I am writing this plugin in Kotlin though.
. (Both compile when Gradle runs on Java 8 though.)
.
.