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

[Fernando Guallini]

Thanks for your comments.
Below you can find a new web rev version that includes a test description in a comment:
http://cr.openjdk.java.net/~fyuan/fernando/8209774/webrev.01/ <http://cr.openjdk.java.net/~fyuan/fernando/8209774/webrev.01/>

I will also create a JBS ticket to revisit this test and remove it if obsolete, if that is fine with you.

-Fernando

> On 11 May 2020, at 17:27, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> 
> 
> 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
>> 
>