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.fu...@oracle.com
<mailto:daniel.fu...@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
