RFR 8245194: Unix domain socket channel implementation

[Michael McMahon]

Thanks for the reviews of the API for this work (JEP 380). The CSR has 
been approved.

So, I would like to continue with the implementation review. The full 
webrev can be found at:

http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.8/

Comments welcome.

Thanks,

Michael

On 31/07/2020 14:45, Michael McMahon wrote:
> Hi Chris,
>
> On 31/07/2020 13:30, Chris Hegarty wrote:
>> Michael,
>>
>>> On 29 Jul 2020, at 18:11, Michael McMahon 
>>> <michael.x.mcmahon at oracle.com> wrote:
>>>
>>> Alan,
>>>
>>> I have incorporated your comments in a .7 version of the review
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.7/
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.7/
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.7/overview-summary.html 
>>>
>>>
>> I think that this looks very good, as is.
>>
>> Thanks for experimenting with the API point to expose the protocol 
>> family of the channel’s socket. It didn’t seem to provide the 
>> tightening of the spec that I expected, and I can see that you did 
>> quite a good job with the textual definitions in the package 
>> description - this may be sufficient for now, but FTR I will note 
>> that it is not possible to always determine the protocol family of a 
>> channel, and it is never possible without explicit permissions being 
>> granted ( hmm.. how does one assert minimal permissions when invoking 
>> getLocalAddress if the protocol family is unknown ). Anyway, this can 
>> be revisited later if needed.
>
> Yes, in principle that is true. If you are given an unbound channel 
> then you can't determine its protocol family without trying to bind 
> it. Though you can determine the type from a bound channel, with a 
> security manager as you will still get an appropriate SocketAddress 
> sub-type instance without any special permissions.
>
> I had thought one use case could be inherited channels, but I don't 
> think the native APIs guarantee you can determine the family of an 
> unbound socket either and it may be the case that such sockets cannot 
> be handled anyway. But, we can come back to this later as you say, if 
> necessary.
>
> Thanks,
>
> Michael.
>