On 02/04/2020 09:48, Daniel Fuchs wrote:
:
DefaultInterface might be better in a test infra class (in java/net)
to avoid duplicate it in several tests.
I have considered that. The problem is that it requires the test that
uses it to add @modules java.base/java.net:+open directive in the test
itself. At the moment only one test uses it - so there is no
duplication (yet). Maybe we should wait until we need it elsewhere
before thinking of ways to move it to the test library?
Okay, I was assuming it would end up being used by several
MulticastSocket tests.
:
When I ran this test it was failing in timeout with *no* traces.
I hate that. I added traces to figure out at which point it was
failing. There might be a bit of duplication in the information,
but I'd rather have that than wonder if the test is actually
doing what I think it does. When unexplainable things happen,
I start doubting everything ;-)
If you insist I'll reluctantly remove the redundant information,
but I do think it helps.
All I'm asking is that additional tracing being consistent with the
existing traces. Stack traces and thread dumps the most useful when
there is a timeout or test timeout. I wonder if there is an issue with
the timeout/failure handler right now so you should have got one here in
the event that the receive blocks indefinitely.
-Alan
