RFR 8245194: Unix domain socket channel implementation

Michael McMahon michael.x.mcmahon at oracle.com
Fri Jul 31 13:45:37 UTC 2020


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.



More information about the nio-dev mailing list