Re: RFR[8243999]: ’DatagramSocket and MulticastSocket constructors don't specify how a null InetAddress is handled'

Hi Patrick, MulticastSocket.java: 195 * @throwsIllegalArgumentException if port is href="#PortRange"> 196 *out of range. I believe this should be: 195 * @throwsIllegalArgumentException if port is href="DatagramSocket.html#PortRange"> 196 *

Re: RFR[8246132]: 'AsynchronousSocketChannelNAPITest failing with a NotYetConnectedException'

Yes! Looks good to me Patrick. Just remove 8246132 from the @bug list. You don't list the bug number when the bug is in the test itself. That's why the bug has a noreg-self keyword. No need for a new webrev. best regards, -- daniel On 05/06/2020 12:36, Patrick Concannon wrote: Hi Alan, That

Re: RFR[8246132]: 'AsynchronousSocketChannelNAPITest failing with a NotYetConnectedException'

Hi Alan, That’s much more concise. Thanks for the tip! I’ve incorporated it into the updated webrev below. http://cr.openjdk.java.net/~pconcannon/8246132/webrevs/webrev.01/ Kind regards, Patrick > On 5 Jun 2020, at 06:33, Ala

RFR[8243999]: ’DatagramSocket and MulticastSocket constructors don't specify how a null InetAddress is handled'

Hi, Could someone please review my patch and CSR for JDK-8243999 - ’DatagramSocket and MulticastSocket constructors don't specify how a null InetAddress is handled’? Currently, several constructors from DatagramSocket and MulticastSocket don't specify that the socket will be bound to the wildc

Re: RFR: 8246431: java/net/httpclient/PathSubscriber tests fail due to missing FilePermission

Julia, > On 4 Jun 2020, at 17:24, Julia Boes wrote: > > Hi, > > The tests in java/net/httpclient/PathSubscriber don't grant certain file > permissions to test library classes. The tests succeed by chance when the > compiled library classes are placed under ${test.classes}, but occasionally >