RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java

[Alan Bateman]

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.

-Alan