On 27/05/2019 19:37, Chris Hegarty wrote:
:
Thanks, both issues resolved in-place.
Looks good.
:
ServerSocket options are mentioned here as that is the behaviour in
the current shipping release ( to return the server related options ), not
the client related ones, see
http://hg.openjdk.
Alan,
> On 27 May 2019, at 17:11, Alan Bateman wrote:
>
> On 27/05/2019 16:48, Chris Hegarty wrote:
>>
>>
>> Updated webrev:
>> https://cr.openjdk.java.net/~chegar/8224477/webrev.04/
> This version looks good.
>
> A minor nit is that there's a blank line added to SocketChannelImpl.setOption
On 27/05/2019 16:48, Chris Hegarty wrote:
Updated webrev:
https://cr.openjdk.java.net/~chegar/8224477/webrev.04/
This version looks good.
A minor nit is that there's a blank line added to
SocketChannelImpl.setOption that separates a comment from the code that
it documents, I assume this i
Alan,
On 27/05/2019 12:50, Alan Bateman wrote:
..
This looks a good cleanup. There may be an argument to have the default
implementations of get/setOption throw NPE when name is null.
Good point. Done.
Does isServer need to be package-private? I didn't spot any usages in
PSI/PDSI.
Not yet
On 27/05/2019 11:48, Chris Hegarty wrote:
This next iteration addresses all of Alan's comments and suggestions.
Additionally, while here we can take the opportunity to cleanup the spec
inconsistencies of the getOption/setOption methods across the socket
impls. The current default implementation
On 24/05/2019 08:28, Alan Bateman wrote:
On 23/05/2019 17:32, Chris Hegarty wrote:
...
This next iteration addresses all of Alan's comments and suggestions.
Additionally, while here we can take the opportunity to cleanup the spec
inconsistencies of the getOption/setOption methods across the
On 23/05/2019 17:32, Chris Hegarty wrote:
Thank you Alan,
I believe that I addressed all your comments and suggestions.
Additionally, while here I noticed an issue where these methods were not
always consistent with their spec to throw IOException when the socket
has been closed.
https://cr.op
Thank you Alan,
I believe that I addressed all your comments and suggestions.
Additionally, while here I noticed an issue where these methods were not
always consistent with their spec to throw IOException when the socket
has been closed.
https://cr.openjdk.java.net/~chegar/8224477/webrev.02/
-
On 22/05/2019 13:54, Chris Hegarty wrote:
While we're here, let's address both the NPE and the IAE.
Okay, I only mentioned it because the JIRA issue had two cases. Also
it's one that we came across when working on the new implementation (it
is called out as a compatibility difference in the Ri
Alan,
> On 21 May 2019, at 20:05, Alan Bateman wrote:
>
> On 21/05/2019 19:36, Chris Hegarty wrote:
>> The get/setOption methods of java.net Socket, ServerSocket, and
>> DatagramSocket, are specified to throw NullPointerException if the given
>> option name is null ( rather than UnsupportedOpera
On 21/05/2019 19:36, Chris Hegarty wrote:
The get/setOption methods of java.net Socket, ServerSocket, and
DatagramSocket, are specified to throw NullPointerException if the given
option name is null ( rather than UnsupportedOperationException, which
is currently thrown ). The implementation corre
11 matches
Mail list logo
