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

[Joe Wang]

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
>