RFR: JDK-8184770: JDWP support for IPv6

[Alex Menkov]

Hi Chris,

On 04/01/2019 04:50, Chris Hegarty wrote:
> Alex,
> 
> On 29/03/2019 22:07, Alex Menkov wrote:
>> (added net-dev as suggested by Alan)
>>
>> Net gurus, please assist in reviewing socket-related code.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/
> 
> Specifically on SocketTransportService.java. What Arthur has
> proposed is better ( changing to lastIndexOf alone is not
> sufficient ). Or is your assumption that the IPv6 literal is
> not enclosed in square brackets?

I didn't know about enclosing IPv6 in square brackets, but looks like 
that's standard way to alleviate conflict between IPv6 address and colon 
as port separator.
Will update the fix to handle them in both JDI connectors 
(SocketTransportService.java) and debugger agent (socketTransport.c)

> 
> If keeping Arthur's `static class HostPort` please make the
> fields final.
> 
>  >> Would it make sense to support the preference properties?
>  >>    java.net.preferIPv4Stack
>  >>    java.net.preferIPv6Addresses
> 
> I'm not sure about this, especially given the property name
> prefixes. I need to think a little more on it.

In the initial version of the fix I didn't check the properties.
The rationale here is backward compatibility - is address is empty, old 
debuggers tries to connect to IPv4 address only.
But handling this properties we will better handle clients with 
properties set (as jdb or any other debugger which uses JDI connectors 
are affected by the properties).

BTW fix provided by Arthur implements listening on localhost differently 
- it creates several sockets and binds them to both IPv4 and IPv6 
addresses. But the problem here (and that's the reason I decide to not 
implement it this way) - how to handle the case when we successfully 
bind on one address (for example IPv4), but fail to bind on other (for 
example the port is busy for IPv6 stack). Arthur's version just fail in 
the case (i.e. the whole Java process terminates) and I don't think this 
is good behavior.


> 
> There is quite a bit of new native code, is it possible to
> rewrite any of this in Java, e.g. reading of the system
> properties ( if that is to remain )?

socketTransport.c is a debugger agent which is completely native.

--alex

> 
> -Chris.