RFR: 8004748: clean up @build tags in RMI tests (original) (raw)

Stuart Marks stuart.marks at oracle.com
Wed Dec 12 17:47:29 UTC 2012

On 12/11/12 6:24 PM, Mandy Chung wrote:

Looks fine with me.

I notice that there are cases that still require @build the main class when it contains the source for other interfaces/classes that another class depends on - not a problem.

Right, that's exactly what's going on. To decompress this for other readers :-) for some test class X it's usually not necessary to list X on an @build line. If there is a helper class Y then something like the following usually works:

 @build Y
 @run main X

But sometimes the source file X.java includes an interface N that Y depends on. (Personally, I would never program this way.) :-)

In this case the above doesn't work, and one must do this:

 @build X Y
 @run main X

In the fullness of time it might be nice to split out interfaces like N into their own top-level source files, but I wanted to keep this separate from the cleanup pass of @build tags.

Thanks,

s'marks

Mandy On 12/11/2012 3:53 PM, Stuart Marks wrote: Hi all,

Please review the following gigantic webrev [1] to clean up @build tags in RMI tests. Details underlying this change are in the bug report [2]. Briefly, if test classes listed in @build tags are in the wrong order, this trips over a jtreg problem that in turn causes a cascade of subsequent tests to fail. It's sensitive to the order in which tests run. The problem currently occurs in the jdk7u repo. It doesn't happen in jdk8 right now, but as things shift around it might occur in the future. Naturally, I intend to backport this to 7u once it's in 8. Shifting the @build tags in the test is a workaround for the jtreg bug, but jtreg isn't going to be fixed soon. Besides, the @build tags in the RMI tests needed to be cleaned up anyway. In particular, consolidating multiple @build tags into a single tag speeds up the RMI test run by about 2.5%. I've also taken the opportunity to do a couple of related cleanups in a few places, such as fixing typos, rearranging tags to be in a more consistent order, removing unnecessary classes from @build lines, adding necessary ones, and in one case renaming a file that was spelled differently from the class that it contained. (CheckUnmarshall.java -> CheckUnmarshal.java; there are no textual changes to this file.) Needless to say, all tests pass. In addition, I've run each test individually (i.e., with a clean JTwork directory) to ensure that there were no occurrences of the library class ordering issue that triggers the jtreg bug. Thanks, s'marks

[1] http://cr.openjdk.java.net/~smarks/reviews/8004748/webrev.0/ [2] http://bugs.sun.com/bugdatabase/viewbug.do?bugid=8004748

More information about the core-libs-dev mailing list