RFR(M) : 8181761: add explicit @build actions for jdk.test.lib classes in all :tier2 tests

[Igor Ignatyev]

Chris/Alan,

Although the test itself doesn't launch new VMs,  jdk.test.lib.NetworkConfiguration, which this test directly depends on, depends on jdk.test.lib.Platform which depends on jdk.test.lib.Utils. and j.t.l.Utils depend on jdk.test.lib.process.* classes as it might start new VMs. [1] is the list of classes generated by running java/net/MulticastSocket/JoinLeave.java (w/o this patch) w/ a clean JTwork dir, @build directives were added for all these classes, this is exactly what was recommended by Jon in another thread[2].

Thanks,
-- Igor

[1]
$ find jdk/testoutput/JTwork/classes/java/net/MulticastSocket -name \*.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/Asserts.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/JDKToolFinder.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/JDKToolLauncher.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/NetworkConfiguration.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/Platform.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/process/OutputAnalyzer.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/process/OutputBuffer.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/process/ProcessTools$1.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/process/ProcessTools$2.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/process/ProcessTools$LineForwarder.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/process/ProcessTools$ProcessImpl.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/process/ProcessTools.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/process/StreamPumper$1.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/process/StreamPumper$LinePump.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/process/StreamPumper$Pump.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/process/StreamPumper$StreamPump.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/process/StreamPumper.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/Utils$ThrowingRunnable.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/jdk/test/lib/Utils.class
jdk/testoutput/JTwork/classes/java/net/MulticastSocket/JoinLeave.class

[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048087.html
> If you want a tip for seeing if you have the correct set o0f @build 
> directives for a test ... use jtreg to build/run just that one test by 
> itself in a *clean*/empty work directory.   Look at the classes that 
> were compiled. Were any of the generated classes compiled implicitly, 
> i.e. not mentioned in @build directives?  If so, add suitable @build 
> directives.
> 
> -- Jon

> On Jun 8, 2017, at 3:36 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 08/06/2017 11:11, Chris Hegarty wrote:
>> :
>> Just quickly looking at some of the networking test, e.g. JoinLeave:
>> 
>>   * @bug 4091811 4148753 4102731
>>   * @summary Test java.net.MulticastSocket joinGroup and leaveGroup
>>   * @library /test/lib
>> + * @build jdk.test.lib.NetworkConfiguration
>> + *        jdk.test.lib.Utils
>> + *        jdk.test.lib.Asserts
>> + *        jdk.test.lib.JDKToolFinder
>> + *        jdk.test.lib.JDKToolLauncher
>> + *        jdk.test.lib.Platform
>> + *        jdk.test.lib.process.*
>>   * @run main JoinLeave
>>   */
>> 
>> I believe this test only requires jdk.test.lib.NetworkConfiguration. Is there any
>> reason why the additional build targets are being added?
>> 
> I was just looking at BasicMulticastTests and have the same question. It will confuse everyone that looks at or needs to change these tests. Also I suspect many people adding will (like me) grab the test description from a working test and use that as their starting point, just making this worse, esp. when new helpers are added to jdk.test.lib. I wouldn't object to jdk.test.lib.* but "@build jdk.test.lib.process.*" in tests that aren't launching new VMs is annoying.
> 
> Jon - is it time to write down some guidelines on how @library and @build should be used?
> 
> -Alan