Hi there,
While working on netty I just noticed that a ServerSocket will keep return true
when isBound() is called even after it was closed. Is this by design? I was bit
surprised by this honestly as after the socket is closed there is no way it
will accept any more connections.
If this is by
Hi Arthur,
This looks like a good cleanup to me.
On 10/04/2019 21:39, Arthur Eubanks wrote:
Here's a prototype webrev to see if the approach is okay with you. If it
looks good, I'll continue with the remaining tests I can find. (should I
start a new thread for the webrev?)
http://cr.openjdk.
Norman
The specification on what happens to all socket types was updated many
years ago
in bug id 6505016, but it looks like ServerSocket::isBound was missed
from that effort.
I think we should probably update the spec to reflect current behavior
and be consistent
with the change above. There
Ok thanks… update to the java docs sounds good to me. I was just suprised by
the behaviour :)
> On 11. Apr 2019, at 17:12, Michael McMahon
> wrote:
>
> Norman
>
> The specification on what happens to all socket types was updated many years
> ago
> in bug id 6505016, but it looks like ServerS
Arthur, Daniel,
> On 10 Apr 2019, at 21:39, Arthur Eubanks wrote:
>
> Here's a prototype webrev to see if the approach is okay with you. If it
> looks good, I'll continue with the remaining tests I can find. (should I
> start a new thread for the webrev?)
>
> http://cr.openjdk.java.net/~aeuba
On 11/04/2019 17:01, Chris Hegarty wrote:
Yes, this is a good point. What’s nice about this is that there is just
one body of code that provides the functionality ( and it is all in
Java, not native). I'm interested to see how this performs in Arthur's
experiments, and I need to do a little more
Daniel,
> On 11 Apr 2019, at 17:15, Daniel Fuchs wrote:
>
> On 11/04/2019 17:01, Chris Hegarty wrote:
>> Yes, this is a good point. What’s nice about this is that there is just
>> one body of code that provides the functionality ( and it is all in
>> Java, not native). I'm interested to see how
On 10/04/2019, 22:03, Bernd Eckenfels wrote:
Maybe instead of having a MacOS specific algorithm it would be a good
idea to have getLocalHostName generally look up the hostnames from the
Array with a trailing „.“ and only if that Fails have it search with
search Suffix?
Interesting idea.
Hi,
If you need different @requires for different runs, there is a jtreg
feature to define separate tests using separate comment blocks.
/*...
*@requires x
*@run ...
*/
/*
* @requires !x
* @run ...
*/
$.02, Roger
On 04/11/2019 12:01 PM, Chris Hegarty wrote:
Arthur, Daniel,
On 10 Apr
>
> One question is if this is a common network configuration, or is there
> some other way to cause it to happen?
>
It's common enough that when I looked up "lookupAllHostAddr OSX", there's a
fair number of blog posts and stackoverflow posts about the issue that
point to the /etc/hosts workaroun
Hi Alex,
Great debugging feature!
While I'm still reading all the details, could you, please, fix some
minor format issues?
http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketTransportService.java.udiff.html
+ * If host is a literal IPv6 addre
11 matches
Mail list logo
