On Fri, 20 Mar 2026 12:03:06 GMT, Jaikiran Pai <[email protected]> wrote:
> Can I please get a review of this test-only change which proposes to update > the `test/jdk/java/net/DatagramPacket/ReuseBuf.java` test to use a loopback > address? > > As noted in https://bugs.openjdk.org/browse/JDK-8380534, this test uses > non-loopback address to send and receive datagram packets, and has been > failing on some of the macos hosts that we run this test on. Given what the > test was introduced for in https://bugs.openjdk.org/browse/JDK-4424096, it > doesn't necessarily require the use of a non-loopback address. > > The commit in this PR updates the test to use loopback address. Few other > clean ups have been done too, to properly close the resources. > > The updated test now passes on all platforms (I launched multiple test runs). test/jdk/java/net/DatagramPacket/ReuseBuf.java line 72: > 70: System.err.println("server exception: " + e); > 71: e.printStackTrace(); > 72: throw new RuntimeException(e); Throwing an exception in a Thread might not result in the test failing. Have you considered using a CompletableFuture or AtomicReference instead to get potential exceptions from the main thread? I see this part is pre-existing, so maybe it's not an issue to continue throwing here. test/jdk/java/net/DatagramPacket/ReuseBuf.java line 118: > 116: InetSocketAddress destAddr = server.getServerAddress(); > 117: // start the server > 118: new Thread(server).start(); Ideally something should join that thread at the end. Not joining threads created by tests at the end of the tests has been known to cause issues, especially when tests are not run in /othervm. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30335#discussion_r2965543211 PR Review Comment: https://git.openjdk.org/jdk/pull/30335#discussion_r2965564089
