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