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

[Jonathan Gibbons]

A different, more incremental approach, would be to look at the totality 
of the functionality being provided in libraries, and to (re)design the 
libraries to minimize inter-library and inter-package package 
dependencies, with a view to using but minimizing @build directives.  
(Meaning, provide new clean libraries, not update old libraries in place.)

By providing a new properly designed library, you can migrate tests to 
it over time, and not have to do it all at once.   As it is now, the 
suggestion to "clean up test libraries after they are merged in one 
place" seems likely to increase the churn on tests, rather than minimize it.

-- Jon


On 06/08/2017 09: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. 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
>>