RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

2020-03-31 Thread Patrick Concannon
Hi, Could someone please review my fix for JDK-8240533 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.' ? Currently, DatagramSocket throws an IOException when sending to port 0, and doesn't throw when connecting. DatagramChan

Re: Java 14 - Change in InetSocketAddress.toString() behaviour seems to be causing issues

2020-03-31 Thread Jaikiran Pai
Hello Alan, On 30/03/20 1:31 pm, Alan Bateman wrote: > On 28/03/2020 06:43, Jaikiran Pai wrote: >> >> There's an issue raised in Quarkus repo[1], where Apache Kafka >> (embedded) no longer starts on Java 14. From what I can see the root >> cause is this[2]. >> >> JDK-8225499[3] changed the impleme

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

2020-03-31 Thread Lance Andersen
Hi Patrick, I think this looks OK. I might suggest using assertThrows vs expectThrows. While they are the same, assertThrows seems more natural and consistent with the other testNG assert methods. HTH Best Lance > On Mar 31, 2020, at 6:15 AM, Patrick Concannon > wrote: > > Hi, > > Coul

Re: Java 14 - Change in InetSocketAddress.toString() behaviour seems to be causing issues

2020-03-31 Thread Jaikiran Pai
Hello Chris, On 30/03/20 1:49 pm, Chris Hegarty wrote: > Hi Jaikiran, > > Thank you for posting this message to net-dev. > > TL;DR seems like the specific issue raised against Quarkus has been > resolved ( by upgrading to a more recent version of ZooKeeper ). That's correct. > >> So this looks l

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

2020-03-31 Thread Alan Bateman
On 31/03/2020 11:15, Patrick Concannon wrote: Hi, Could someone please review my fix for JDK-8240533 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.' ? Currently, DatagramSocket throws an IOException when sending to port 0,

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

2020-03-31 Thread Daniel Fuchs
This looks good to me Patrick. I'm happy to see that all implementations now have a consistent and predictable behavior. Also - as Alan noted - this is not really a behavioral change as some subclass of IOException (or IOException itself) was already thrown before. +1 best regards, -- daniel

Re: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

2020-03-31 Thread Alan Bateman
On 30/03/2020 19:27, Patrick Concannon wrote: Hi Alan, Thanks for your feedback. I've incorporated your comments into the revised webrev below. http://cr.openjdk.java.net/~pconcannon/8241072/webrevs/webrev.01/ With regards to the UnreferencedXXX tests, I can take a look at these separate

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

2020-03-31 Thread Chris Hegarty
Patrick, > On 31 Mar 2020, at 15:08, Daniel Fuchs wrote: > >> .. >> bug: https://bugs.openjdk.java.net/browse/JDK-8240533 >> webrev: http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.00/ Look good Patrick. The check is deliberately performed after the security manager checks, right

Re: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

2020-03-31 Thread Chris Hegarty
> On 30 Mar 2020, at 19:27, Patrick Concannon > wrote: > ... > > http://cr.openjdk.java.net/~pconcannon/8241072/webrevs/webrev.01/ This looks very good, a testament to all the prior cleanup work that has already been done. Just a few comments: - DatagramSocket::getChannel now stands out a

Re: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

2020-03-31 Thread Alan Bateman
On 31/03/2020 18:27, Chris Hegarty wrote: : - In DatagramSocket::createDelegate, "enable broadcast if possibleā€ - Possibly due to refactoring, but I cannot reconcile this with the old implementation. DatagramSocket is specified to make a best attempt to enable this option so I think it's in