RFR: 8004748: clean up @build tags in RMI tests

[Stuart Marks]

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