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

Hi Jaikiran, By the way, keeping aside the breaking nature of this change, the current javadoc, I think doesn't reflect what the current implementation returns for unresolved addresses. The javadoc states: "If the address is unresolved, || is displayed in place of the address literal." Not

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

> On 31 Mar 2020, at 18:46, Alan Bateman wrote: > > 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

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

On 01/04/20 3:49 pm, Julia Boes wrote: > > Hi Jaikiran, > By the way, keeping aside the breaking nature of this change, the current javadoc, I think doesn't reflect what the current implementation returns for unresolved addresses. The javadoc states: "If the address is unr

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

> On 1 Apr 2020, at 13:48, Jaikiran Pai wrote: ... >>> Now that you explained it to me, I see what you mean and what that javadoc >>> means. I hadn't paid attention to the "This String is constructed by >>> calling toString() on the InetAddress and concatenating the port number >>> (with

RFR [15] 8241988 DatagramSocket incorrectly caches the first set of socket options

DatagramSocket incorrectly caches the first set of socket options that it encounters (through an invocation of supportedOptions()), subsequently returning that set of options regardless of what the particular datagram socket impl actually supports. Webrev: https://cr.openjdk.java.net/~chegar/824

Re: RFR [15] 8241988 DatagramSocket incorrectly caches the first set of socket options

Hi Chris, just looking at the supportedOptions method in the two classes DatagramSocket and MulticastSocket, if I haven't misread them, are they not the same? As such MulticastSocket could inherit that method from DatagramSocket ? (without the necessity to override) regards Mark ___

Re: RFR [15] 8241988 DatagramSocket incorrectly caches the first set of socket options

> On 1 Apr 2020, at 15:12, mark sheppard wrote: > > Hi Chris, > just looking at the supportedOptions method in the two classes > DatagramSocket and MulticastSocket, if I haven't misread them, are > they not the same? > As such MulticastSocket could inherit that method from DatagramSocket ?

Re: RFR [15] 8241988 DatagramSocket incorrectly caches the first set of socket options

Looks good to me Chris! best regards, -- daniel On 01/04/2020 16:04, Chris Hegarty wrote: On 1 Apr 2020, at 15:12, mark sheppard > wrote: Hi Chris,       just looking at the supportedOptions method in the two classes DatagramSocket and MulticastSocket, if I ha

Re: RFR [15] 8241988 DatagramSocket incorrectly caches the first set of socket options

thanks Chris :+1 regards Mark - Original Message - From: chris.hega...@oracle.com To: macanao...@hotmail.com, mark.shepp...@oracle.com, net-dev@openjdk.java.net Sent: Wednesday, 1 April, 2020 4:04:33 PM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: RFR [15] 8241988 D

Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found

Hi Michael et al., just looking at the webrev ... the change in URLClassPath seems reasonable. The change in JarURLConnection has implications and would change the semantics of the getJarFile method. using the example accompanying this JBS item to demonstrate an issue caused by the caching

Re: RFR [15] 8241988 DatagramSocket incorrectly caches the first set of socket options

On 01/04/2020 16:04, Chris Hegarty wrote: : Updated webrev: https://cr.openjdk.java.net/~chegar/8241988/webrev.01/ Looks good although I can't immediately see why options is package private I assume the tests runs in /othervm because of the setDatagramSocketImplFactory. -Alan

8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

Hi, Please find below a fix for: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available" https://bugs.openjdk.java.net/browse/JDK-8241786 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.01/ The real fix is

Re: RFR [15] 8241988 DatagramSocket incorrectly caches the first set of socket options

> On 1 Apr 2020, at 17:51, Alan Bateman wrote: > > On 01/04/2020 16:04, Chris Hegarty wrote: >> : >> >> Updated webrev: >> https://cr.openjdk.java.net/~chegar/8241988/webrev.01/ >> > Looks good although I can't immediately see why options is package private It can be private. I’ll make that

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

On 01/04/2020 18:42, Daniel Fuchs wrote: Hi, Please find below a fix for: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available" https://bugs.openjdk.java.net/browse/JDK-8241786 webrev: http://cr.openjdk.java.net/~dfuch

Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found

p.s. I had also meant to say in the response below, that the proposed getJaFile solution is perfectly reasonable and would allow a recoverable strategy in an related scenario where a URLConnection:: connect, for the same type of entry URL, throws a FNFException resulting in the same type of "re