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.bate...@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 >
