Hi Alan,
> ...why these API classes are still being distributed in 2019...
> ...none of this makes sense since Java SE 9 as both
> JSR-206 and JSR-173 ceased to be standalone technologies...
You've put what I was thinking all along, into the perfect words there.
Thanks, Alan.
If you can answer a few questions for me please Alan, you could help
salvage the little sanity I have left after wrestling with this:
1. What's the correct command to patch javax.xml and jdk.xml.dom with
Gradle's API JAR?
2. If it is actually impossible to patch either of them with Gradle,
what's your best guess for why that might be?
3. How can I _exclude_ javax.xml and jdk.xml.dom from the module graph?
• I have already tried --limit-modules, but haven't had any luck
In the meantime, I will try to muster up the will to report the issue
to the Gradle devs.
TIA
-------- Original Message --------
Subject: Re: Seeking Assurance That Patching gradle-api-6.{...}.jar Is
At Least Technically Possible - Somehow
From: Alan Bateman <alan.bate...@oracle.com>
Date: Tue, November 12, 2019 1:04 am
To: Plugins <plug...@lingocoder.com>, jigsaw-dev@openjdk.java.net
On 12/11/2019 02:30, Plugins wrote:
> Hi all,
>
> I might have spoken too soon in my last October email [1]. Ever since,
> I've
> been having a hell of a time trying to get Gradle's so-called
> „shaded“ API jar
> to play nicely with the other modules in my JPMS-build-enabling Gradle
> plugin [2]
>
> For some reason, Gradle's generated artifact redundantly duplicates all
> the
> packages of two modules from the JDK: javax.xml and jdk.xml.dom.
The Gradle devs will know but I assume these are coming from the
xml-apis-${version}.jar (Apache Xerces project). It's not clear, to me
anyway, why these API classes are still being distributed in 2019. The
XML processing API was added to Java SE 1.4, the XML stream API came a
bit later. The XML APIs started out in Java SE as "standalone
technologies" where they were in the JDK but could be upgraded by
deploying a newer version with the endorsed standards override
mechanism. It's possible, and probable, that developers have been
deploying xml-apis on the class path and got lucky that it didn't cause
problems. Anyway, none of this makes sense since Java SE 9 as both
JSR-206 and JSR-173 ceased to be standalone technologies (see the final
MR for both JSRs), and mechanism to upgrade them (the endorsed standards
override mechanism) has been removed.
-Alan.
