RFR: JDK-8184770: JDWP support for IPv6

[Alex Menkov]

Updated webrev:
http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/

- added support for addresses enclosed in square brackets;
- updated SocketTransportService.java to handle empty hostname the same 
way as JDWP agent (listen/attach to loopback address);
Has to update nsk/jdi/ListeningConnector/startListening/startlis001.java
(all other com/sun/jdi, nsk/jdi, nsk/jdwp, nsk/jdb test are passed).

--alex

On 04/01/2019 11:21, Alex Menkov wrote:
> 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.