On 5/11/2020 2:32 AM, Alan Bateman wrote:
On 08/05/2020 18:19, Fernando Guallini wrote:
Hi Daniel and Alan,
@compile/module=java.xml was my first try, but for the nature of this
test, it didn't work. The reason is that the original shell test does
the following:
- Compiles it’s own version of Node and Document interfaces
- Compiles DocumentImpl patching java.xml with those 2 interfaces
- Executes the AbstractMethodErrorTest patching the java.xml module
*only with DocumentImpl* patch(not including Document and Node)
It does that by keeping the patches output in different folders.
That’s important otherwise AbstractMethodErrorTest doesn’t compile,
because it references some methods not declared in its custom
interfaces, and it seems to be coded this way to reproduce the
original bug. That is also the reason why I added the
*@clean* command to remove Document and Node *before* running the test.
But when using *@compile/module=java.xml*, under the hood, JTREG
generates a folder named “patches/java.xml/..” including all the
compiled classes under it. Unfortunately, the temporary interfaces
can’t be removed because *@clean* does not know how to resolve the
path "/patches/java.xml/..”.
To sum up, this test creates a temporary java.xml patch that needs to
be ignored after compiling *DocumentImpl. *I am using —patch-module
because it’s more flexible than @compile/module
*
*
Hope I explained myself!
This may be a question for Joe Wang but I'm curious if this need to
override/upgrade W3C DOM API classes dates back to when it was an
endorsed standard that could be overridden with the endorsed standards
override mechanism. The @bug on the test suggests otherwise but I'm
curious if it make any sense with JDK 9+. This doesn't impact the good
work to replace the script of course, I'm just curious how separately
compilation issue arises here.
I agree with you, Alan, that this test is obsolete. I just haven't
thought of getting rid of it. But you're right, it can be removed instead.
-Joe
-Alan
