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.w...@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 >> >
