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

[Fernando Guallini]

Sure, I will add some of the explanation as a comment. Thank you Daniel!

> On 8 May 2020, at 18:39, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Fernando,
> 
> Ah - I see the keypoint is the:
>  39  * @clean org.w3c.dom.*
> OK, I missed that. Then I agree - ignore my previous comments.
> 
> Maybe the explanations below should be added to the test in some
> comment to help future maintainers (and reviewers).
> 
> best regards,
> 
> -- daniel
> 
> 
> 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!
>>> On 8 May 2020, at 15:49, Daniel Fuchs <daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>> wrote:
>>> 
>>> On 08/05/2020 15:40, Alan Bateman wrote:
>>>>>   31 /*
>>>>>   32  * @test
>>>>>   33  * @bug 8035437
>>>>>   34  * @summary Tests that java.lang.AbstractMethodError is not thrown when
>>>>>   35  * serializing improper version of DocumentImpl class.
>>>>>   36  * @library /test/lib
>>>>>       * @modules javax.xml/org.w3c.dom
>>>>>       *          javax.xml/com.sun.org.apache.xerces.internal.dom
>>>>>   40  * @run main/othervm --patch-module java.xml=${test.class.path} AbstractMethodErrorTest
>>>>>   41  */
>>>>> 
>>>>> (not 100% sure the @modules is even needed)
>>>> I wouldn't expect to need --patch-module here. Instead maybe it could be changed to use @compile/module=java.xml ... and jtreg should compile and run the overrides "as if" they are in the java.xml module. There are a couple of examples of this in the test suite that might help get this going. No need for javax.xml/org.w3c.dom as that package is already exported.
>>> 
>>> Right. Copy paste error. The --patch-module shouldn't be needed
>>> anywhere. Good point about @compile - the main class
>>> AbstractMethodErrorTest is not in the patched module, so
>>> the patched classes may not get compiled if you don't force
>>> their compilation.
>>> 
>>> Thanks for the correction Alan!
>>> 
>>> -- daniel
>