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/view_bug.do?bug_id=8004748
