Hi Daniel, Thanks for pointing this out.
Please find the corrections in the updated webrev below. http://cr.openjdk.java.net/~pconcannon/8240901/webrevs/webrev.01/ Kind regards, Patrick > On 11 Aug 2020, at 16:41, Daniel Fuchs <daniel.fu...@oracle.com> wrote: > > Hi Patrick, > > I thought I had mentioned it before, but the DatagramChannel test > looks wrong: if I am not mistaken the assertTrue check that compare > the two buffers will always succeed, even if the data in the two > buffers is different. It only requires that the two buffers are > filled to their limit: > > 1. Can you add a system.println before verifying that the two > buffers are equals, that prints both buffers' positions and limit? > > 2. Can we use assertEquals instead of assertTrue? > > 3. hint: there are two lines that need to be moved around (at two > different places) and that should become clear when you look at > the traces printed in 1. > > best, > > -- daniel > > > On 11/08/2020 15:43, Patrick Concannon wrote: >> Hi, >> Could someone please review my fix for JDK-8240901 — ‘Add a test to check >> that large datagrams are sent/received on the network correctly’ ? >> The tests `java/net/DatagramSocket/SendReceiveMaxSize.java` and >> `java/net/DatagramSocket/SendReceiveMaxSize.java` have been updated to check >> (on all platforms) that the sending and receiving of large datagrams across >> a network are sent, fragmented, and re-assembled correctly. Previously, this >> check was performed on macOS only. >> issue: https://bugs.openjdk.java.net/browse/JDK-8240901 >> webrev: http://cr.openjdk.java.net/~pconcannon/8240901/webrevs/webrev.00/ >> Kind regards, >> Patrick >
