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

Fernando Guallini fernando.guallini at oracle.com
Fri May 8 17:19:10 UTC 2020


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> 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



More information about the core-libs-dev mailing list