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

[Ioi Lam]

On 6/8/17 9:18 AM, Igor Ignatyev wrote:
> Alan,
>
> I totally agree there are many places which we need to clean up in testlibraries, including these weird dependencies, but it would be much easier to clean up test libraries after they are merged in one place. personally I don't think that NetworkConfiguration depending on Platform is a problem, I'd even say that NetworkConfiguration reimplementing methods from Platform is a problem. however even if we remove such dependencies now, one harmless refactoring of test libraries might get us back to instability of test results. it seems Jon has some ideas how to improve this situation, Ioi and I had several discussions about that as well, I believe we can come out w/ an elegant solution for this problem quite soon.

Yes, we need a mechanism where a library's dependencies are expressed by 
the library itself, and not to be discovered and maintained by each 
individual test case.

It seems like turning our test libraries into Jigsaw modules would help. 
Igor and I are looking into the details and see how we can do that for 
the JDK and HotSpot test libraries.

Thanks
- Ioi

>   meanwhile I'd echo Jon and recommend to apply these fixes to solve our current test execution problem.
>
> -- Igor
>   
>> On Jun 8, 2017, at 8:52 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>> On 08/06/2017 16:24, Igor Ignatyev wrote:
>>> 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].
>>>
>> A long back, I wrote NetworkConfiguration to allow tests probe the network configuration. Chris did work in this area in recent times with a new version in test/lib/testlibrary. Now it seems to have moved again and has got tangled up in other test infrastructure. I appreciate that your are trying to do the right thing and centralize the test infrastructure but it's causing a lot of problems with test execution in jdk10/jdk10 and also making the tests much harder to maintain. Maybe the right thing it to clean up the test infrastructure first and eliminate all the cross package dependences before going further on this project.
>>
>> -Alan
>>