From paul.sandoz at oracle.com  Wed Jul  1 22:33:54 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 1 Jul 2020 15:33:54 -0700
Subject: 8219014: (bf) Add absolute bulk put methods which accept a source
 Buffer
In-Reply-To: <18AEADCF-52D6-4D6D-9F07-976631CE96CB@oracle.com>
References: <5F6F4823-8B99-48DB-9B7A-44CF2A3DADBD@oracle.com>
 <45CBA103-32F0-46FE-8444-35828A990733@oracle.com>
 <87wo8ti01g.fsf@oldenburg2.str.redhat.com>
 <824238F5-D399-4088-A1AA-A9AC8321577F@oracle.com>
 <87eev1hwxa.fsf@oldenburg2.str.redhat.com>
 <EC834E5F-0E3E-456B-BBA2-457F81098D3D@oracle.com>
 <8736bhhvst.fsf@oldenburg2.str.redhat.com>
 <6B7BB465-EA1F-4763-8E2D-927B71EADFC6@oracle.com>
 <87imjsxk4j.fsf@oldenburg2.str.redhat.com>
 <65CD68C6-07A8-4811-B4FD-0F1277DA8697@oracle.com>
 <87y2rfi8og.fsf@oldenburg2.str.redhat.com>
 <805C5BDD-C826-4C61-A9A8-11656FD71267@oracle.com>
 <E9FEFC18-1E31-4F18-8F89-720253F53D62@oracle.com>
 <35F64B3C-BC66-4788-8200-44AB7E321845@oracle.com>
 <18AEADCF-52D6-4D6D-9F07-976631CE96CB@oracle.com>
Message-ID: <FF5E6B44-0F40-464E-B9FD-E30D2A5DD912@oracle.com>

HI,

The CSR looks ok, but I think you will need to add specdiff and then you can present the JavaDoc of the ByteBuffer absolute put method deferring to the specdiff for the other cases.

The JavaDoc in the webrev looks good.

Paul.

> On Jun 26, 2020, at 5:49 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> 
>> On Jun 26, 2020, at 9:25 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>> You previous work laid the foundations such that this feature is predominantly API and test work (and ensuring that annoying buffer backed by CharSequence or String, I forget which, is not misbehaving).
>> 
>> I am inclined to proceed.
> 
> CSR filed [1].
> 
> Thanks,
> 
> Brian
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8248431
> 


From macanaoire at hotmail.com  Thu Jul  2 00:13:46 2020
From: macanaoire at hotmail.com (mark sheppard)
Date: Thu, 2 Jul 2020 00:13:46 +0000
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
Message-ID: <DBBPR09MB301407471575A08F8CCE817FDF6C0@DBBPR09MB3014.eurprd09.prod.outlook.com>

Hi Michael,



A couple of comments and observations from the API perspective


Trojan work done here.

Looking at the API - overall it looks reasonably good, but there are possibly a few inconsistencies,

at least in my interpretation.


I have some reservations about the representation of unix domain sockets as an integral part of

SocketChannel and ServerSocketChannel, which will be addressed further below.


A couple of small points;


? Open, bind, connect methods ??


* Does open(SocketAddress remoteAddress) result in an implicit bind for the returned SocketChannel?

The implementation note infers that this is an automatic assignment in the case of a connect on an unbound

Unix domain SocketChannel.

Inference here is that this open includes an implicit connect, which in turn would include an implicit bind ?


* The no args open create a SocketChannel/ServerSocketChannel for an Internet protocol


41  * <p> A server-socket channel is created by invoking one of the {@code open}

  42  * methods of this class. The no-arg {@link #open() open} method opens a server-socket

  43  * channel for an <i>Internet protocol</i> socket. The {@link #open(ProtocolFamily)}

  44  * method is used to open a server-socket channel for a socket of a specified

  45  * protocol family.



122      * Opens a server-socket channel for an <i>Internet protocol</i> socket.

ServerSocketChannel::open()


As such,  does this mean that a subsequent bind with a UnixDomainSocketAddress will fail  for this unbound {Server}SocketChannel?


And similarly if an open(ProtocolFamily) is invoked with one of INET, INET6 or UNIX, then

are there any constraints on a subsequent bind  on that {Server}SocketChannel ?

Or constraints on SocketChannel::connect

For example, if INET was specified does that mean only a SocketAddress representing an IPV4 address

may be bound and similarly INET6 then only an IPV6 address, and lastly will UNIX constrain bind and connect

using a UnixDomainSocketAddress ?

And  in each case an appropriate Exceptions will be thrown to indicate the invalid binding.


? UnixDomainSocketAddress ??


If a UnixDomainSocketAddress is provided to a {Server}SocketChannel::bind,  after creation with an open taking an INET or INET6 argument, will

an Exception be thrown ?


* Is an unnamed SocketAddress extant on an unbound unix domain SocketChannel? That is to say getLocalAddress will return an UnixDomainSocketAddress representing unbound address or should it return null ?


In the module description documentation


 343  * <p><i>Internet Protocol</i> sockets support network communication using TCP/IP and

 344  * are addressed using {@link InetSocketAddress}es which encapsulate an IP address

 345  * and port number. <i>Internet Protocol</i> sockets are the default kind created,

 346  * when a protocol family is not specified in the channel factory creation method.


But Internet Protocol sockets also includes UDP which are abstracted as DatagramChannel, and SCTP which is an

SctpChannel in jdk.sctp module.

This is not a big deal, and I understand what is being said but it somehow doesn?t read so fluidly, from a pedantic perspective.

It is  as if it is trying to be abstract and  be non committal on the protocol.

SocketChannel and SeverSocketChannel have been up to this point synonymous with TCP. The underlying protocol

is TCP so I think it could be stated explicitly.


 ? UnixDomainSocketAddress spec


  41  * <p> An <a id="unnamed"></a><i>unnamed</i> {@code UnixDomainSocketAddress} has

  42  * an empty path. The local address of a Unix domain socket that is automatically

  43  * bound will be unnamed.


WRT UnixDomainSocketAddress an unnamed address equates to an empty PATH ? rather than a null PATH


But an empty Path is significant, as  per PATH spec stated below


A Path is considered to be an empty path if it consists solely of one name element that is empty.

Accessing a file using an empty path is equivalent to accessing the default directory of the file system.


Also this infers that auto bound sockets have unnamed representations. However, this is at variance with ServerSocketChannel


 234      * @apiNote

 235      * Binding a channel to a <i>Unix Domain</i> socket creates a file corresponding to

 236      * the file path in the {@link UnixDomainSocketAddress}. This file persists

 237      * after the channel is closed, and must be removed before another socket can

 238      * bind to the same name. Binding to an address that is automatically assigned

 239      * will create a unique file in some system temporary location. The associated

 240      * socket file also persists after the channel is closed. Its name can be

 241      * obtained from the channel's local socket address.


There are also some contractions in the following with UnixDomainSocketAddress spec, in that auto binding for

SocketChannel and ServerSocketChannel are distinct procedures:


 361  * If a Unix domain {@link SocketChannel} is automatically bound by connecting it

 362  * without calling {@link SocketChannel#bind(SocketAddress) bind} first, then its

 363  * address is <i>unnamed</i>; it has an empty path field, and therefore has no

 364  * associated file in the file-system. Explicitly binding a {@code SocketChannel}

 365  * to any unnamed address has the same effect.

 366  * <p>

 367  * If a Unix domain {@link ServerSocketChannel} is automatically bound by passing a

 368  * {@code null} address to one of the {@link ServerSocketChannel#bind(SocketAddress) bind}

 369  * methods, the channel is bound to a unique name in the temporary directory identified

 370  * by the {@code "java.io.tmpdir"} system property. The exact pathname can be obtained by

 371  * calling {@link ServerSocketChannel#getLocalAddress() getLocalAddress} after bind returns.

 372  * It is an error to bind a {@code ServerSocketChannel} to an unnamed address.


Why not auto bind SocketChannel using similar mechanism to that of ServerSocketChannel, and have the unnamed

address to explicitly represent an unbound SocketChannel?



In any case all is hunky dory when considering SocketChannel encapsulating a unix domain socket in the context of

sending and receiving data. However, unix domain sockets have additional capabilities and functionality which distinguish

them from a TCP counterpart.  This is in terms of sending file descriptors and capabilities. This is significant functionality.

So much so, that it should be at least considered they are represented by  their own distinct set of abstractions, analogous to SctpChannel.

This could be done through either subclassing {Server} SocketChannel or placing a relevant set of abstractions at the same

in the SelectableChannel hierarchy


I think having a separate set of abstractions for ?unix domain sockets? would make them easier to use, allow for easier specification of the additional

functionality and behaviour and  leave SocketChannel and ServerSocketChannel synonymous with the TCP protocol.


As such, an abstraction such as:

 * LocalChannel, LocalServerChannel, or

 * LocalSocketChannel, LocalServerSocketChannel, or

 * LocalDomainChannel, LocalDomainServerChannel

Are worth considering


Some motivating factors for suggesting a separate set of api abstractions  are:


It will more clearly separate out the underlying protocol domains.


Provides clearer and cleaner semantics. For example, other than the fact that a TCP socket

and Unix domain socket exhibit stream behaviour, a Unix domain socket can exhibit

different behaviour in connection establishment, send/receive behaviour;

they not subject to flow control etc, and may exhibit different reliability semantics,

in that it is possible for a sender to flood a receiver.


They have a different access model in being subject to OS level permission on the OS filesystem.

This leads to different bind behaviour, connect behaviour - different causes for IOException or SocketException.

They use a different ?socket address? namespace i.e. the filesystem name space.

Close behaviour is different - requires additional explicit management of the socket domain

namespace in the filesystem.


Having separate API abstractions allows for specific descriptions and specification for those abstractions

Having a separate abstraction will provide cleaner, more precise and clearer semantics for a Unix domain channel abstraction

Allows for clearer, more precise specification definition, and developer documentation, avoiding possible ambiguities.



Eliminates the StandardProtocolFamily extensions

BUT will require addition of openLocalChannel/openLocalServerChannel methods to SelectorProvider


Eliminates socket method and throwing of UnSupportedException


backward compatibility in the API - SocketChannel and ServerSocketChannel remain as they are

and the new functionality is defined in a new distinct set of abstractions


Allows for easier integration  of the additional features and functionality associated with unix domain sockets,

for example, the passing of file descriptors, or capability exchanges (sendCredential, receiveCredential).


File descriptor passing can be easily included in a separate abstraction (e.g. LocalChannel), with additional methods,

such as  ** sendFD(FileDescriptorn fd)  **,   ** receiveFD(FileDescriptor fd) ** provided for the purpose or even with

an overloaded send and receive method.

Thus, avoiding the need to retrofit such extended functionality into the existing SocketChannel api.



Of course, alternatively such functionality could be supported by a mediating utility abstraction, such as FileDescriptorExchanger::send(FileDescriptor, SocketChannel)  FileDescriptorExchanger::recv(FileDescriptor, SocketChannel) for the purpose of exchanging file descriptors.


In short a Unix domain socket is a different functional abstraction, which has different and extended behaviour.

As such defining a separate API abstraction provides for clear, unambiguous behaviour, making easier to use, and

allowing for easier integration of additional extended behaviour.


best regards
Mark

________________________________
From: nio-dev <nio-dev-bounces at openjdk.java.net> on behalf of Michael McMahon <michael.x.mcmahon at oracle.com>
Sent: Thursday 18 June 2020 14:31
To: nio-dev at openjdk.java.net <nio-dev at openjdk.java.net>
Subject: RFR 8245194: Unix domain socket channel implementation


Hi,

I'd like to start the review for JEP-380 (Unix Domain Socket Channels) [1]. The first and smaller part of this JEP (8241305: Add protocol specific factory creation methods to SocketChannel and ServerSocketChannel) has already been integrated in JDK 15. This main part of the JEP will hopefully be targeted to 16 under this bugid (8245194 Unix Domain socket channel implementation [3])

The full webrev [4] touches a lot of files, so I have put the public API change in a separate webrev at [5] and there is a specdiff at [6].

The implementation, while it touches a lot of files, is mostly about re-factoring the existing SocketImpl and ServerSocketImpl implementation classes into separate Inet and Unix variants, along with the new implementation code for Unix domain.

Comments welcome on either the implementation or the API, although I would like to concentrate on the API to start with as I expect the review will have several iterations.

Regards,

Michael.


[1] https://openjdk.java.net/jeps/380

[2] https://bugs.openjdk.java.net/browse/JDK-8241305

[3] https://bugs.openjdk.java.net/browse/JDK-8245194

[4] http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.1/

[5] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.1/

[6] http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.1/overview-summary.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200702/608333fa/attachment-0001.htm>

From brian.burkhalter at oracle.com  Thu Jul  2 20:15:42 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 2 Jul 2020 13:15:42 -0700
Subject: 8219014: (bf) Add absolute bulk put methods which accept a source
 Buffer
In-Reply-To: <FF5E6B44-0F40-464E-B9FD-E30D2A5DD912@oracle.com>
References: <5F6F4823-8B99-48DB-9B7A-44CF2A3DADBD@oracle.com>
 <45CBA103-32F0-46FE-8444-35828A990733@oracle.com>
 <87wo8ti01g.fsf@oldenburg2.str.redhat.com>
 <824238F5-D399-4088-A1AA-A9AC8321577F@oracle.com>
 <87eev1hwxa.fsf@oldenburg2.str.redhat.com>
 <EC834E5F-0E3E-456B-BBA2-457F81098D3D@oracle.com>
 <8736bhhvst.fsf@oldenburg2.str.redhat.com>
 <6B7BB465-EA1F-4763-8E2D-927B71EADFC6@oracle.com>
 <87imjsxk4j.fsf@oldenburg2.str.redhat.com>
 <65CD68C6-07A8-4811-B4FD-0F1277DA8697@oracle.com>
 <87y2rfi8og.fsf@oldenburg2.str.redhat.com>
 <805C5BDD-C826-4C61-A9A8-11656FD71267@oracle.com>
 <E9FEFC18-1E31-4F18-8F89-720253F53D62@oracle.com>
 <35F64B3C-BC66-4788-8200-44AB7E321845@oracle.com>
 <18AEADCF-52D6-4D6D-9F07-976631CE96CB@oracle.com>
 <FF5E6B44-0F40-464E-B9FD-E30D2A5DD912@oracle.com>
Message-ID: <F9A2E585-E3EB-4CB6-9D05-16DEBB77A8C2@oracle.com>

I have attached a specdiff to the CSR [1].

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8248431

> On Jul 1, 2020, at 3:33 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> The CSR looks ok, but I think you will need to add specdiff and then you can present the JavaDoc of the ByteBuffer absolute put method deferring to the specdiff for the other cases.
> 
> The JavaDoc in the webrev looks good


From michael.x.mcmahon at oracle.com  Fri Jul  3 11:38:43 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 3 Jul 2020 12:38:43 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <DBBPR09MB301407471575A08F8CCE817FDF6C0@DBBPR09MB3014.eurprd09.prod.outlook.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <DBBPR09MB301407471575A08F8CCE817FDF6C0@DBBPR09MB3014.eurprd09.prod.outlook.com>
Message-ID: <d5cab997-685b-e04e-3db9-9537e814f499@oracle.com>

Hi Mark,


Thanks for reviewing the spec.


On 02/07/2020 01:13, mark sheppard wrote:
> Hi Michael,
>
>
> A couple of comments and observations from the API perspective
>
>
> Trojan work done here.
>
> Looking at the API - overall it looks reasonably good, but there are 
> possibly a few inconsistencies,
>
> at least in my interpretation.
>
>
> I have some reservations about the representation of unix domain 
> sockets as an integral part of
>
> SocketChannel and ServerSocketChannel, which will be addressed further 
> below.
>
>
> A couple of small points;
>
>
> ? Open, bind, connect methods ??
>
>
> * Does open(SocketAddress remoteAddress) result in an implicit bind 
> for the returned SocketChannel?
>
> The implementation note infers that this is an automatic assignment in 
> the case of a connect on an unbound
>
> Unix domain SocketChannel.
>
> Inference here is that this open includes an implicit connect, which 
> in turn would include an implicit bind ?
>
>
open(SocketAddress) does not itself invoke bind(). Therefore, the API 
note added to bind()
does not apply in this case.


However, there is a distinction between implicit bind (when bind is not 
called)
and "automatic assignment" (where you call bind(null) ), which applies 
with Unix Domain,

but not with TCP/IP sockets. In the case of TCP/IP sockets the result is 
the same. You get
a randomly chosen port number. With Unix domain sockets, implicit bind 
results in an

"unnamed" local address, and therefore no socket file in the 
file-system. This is the most

likely use-case for client sockets with Unix domain.


Whereas an "automatically assigned" address gives you an explicit 
(randomly chosen)

address (a path in the ${java.io.tmpdir} directory). This is equivalent 
to the randomly

chosen port number with TCP.


I think it's important to support both named and unnamed client sockets 
for Unix domain.

So, that is how I ended up with that distinction


Basically, TCP has no concept of an unnamed local port. So, that 
difference has to
be reflected somewhere in the API.


> * The no args open create a SocketChannel/ServerSocketChannel for an 
> Internet protocol
>
>
> 41* <p> A server-socket channel is created by invoking one of the 
> {@code open}
>
> 42* methods of this class. The no-arg {@link #open() open} method 
> opens a server-socket
>
> 43* channel for an <i>Internet protocol</i> socket. The {@link 
> #open(ProtocolFamily)}
>
> 44* method is used to open a server-socket channel for a socket of a 
> specified
>
> 45* protocol family.
>
>
>
> 122* Opens a server-socket channel for an <i>Internet protocol</i> socket.
>
> ServerSocketChannel::open()
>
>
> As such,does this mean that a subsequent bind with a 
> UnixDomainSocketAddress will failfor this unbound {Server}SocketChannel?
>
>
Yes, that should throw UnsupportedAddressTypeException as it does 
currently for unknown address types.
>
> And similarly if an open(ProtocolFamily) is invoked with one of INET, 
> INET6 or UNIX, then
>
> are there any constraints on a subsequent bindon that 
> {Server}SocketChannel ?
>
> Or constraints on SocketChannel::connect
>
> For example, if INET was specified does that mean only a SocketAddress 
> representing an IPV4 address
>
> may be bound and similarly INET6 then only an IPV6 address, and lastly 
> will UNIX constrain bind and connect
>
> using a UnixDomainSocketAddress ?
>
> Andin each case an appropriate Exceptions will be thrown to indicate 
> the invalid binding.
>
>
> ? UnixDomainSocketAddress ??
>
>
> If a UnixDomainSocketAddress is provided to a 
> {Server}SocketChannel::bind,after creation with an open taking an INET 
> or INET6 argument, will
>
> an Exception be thrown ?
>
>
> * Is an unnamed SocketAddress extant on an unbound unix domain 
> SocketChannel? That is to say getLocalAddress will return an 
> UnixDomainSocketAddress representing unbound address or should it 
> return null ?
>
>
Yes, the socket family (set when creating the channel) must be 
compatible with the address type used when binding

and connecting. Otherwise UATE is thrown.

> In the module description documentation
>
>
> *343* <p><i>Internet Protocol</i> sockets support network 
> communication using TCP/IP and*
>
> *344* are addressed using {@link InetSocketAddress}es which 
> encapsulate an IP address*
>
> *345* and port number. <i>Internet Protocol</i> sockets are the 
> default kind created,*
>
> *346* when a protocol family is not specified in the channel factory 
> creation method.*
>
>
> But Internet Protocol sockets also includes UDP which are abstracted 
> as DatagramChannel, and SCTP which is an
>
> SctpChannel in jdk.sctp module.
>
> This is not a big deal, and I understand what is being said but it 
> somehow doesn?t read so fluidly, from a pedantic perspective.
>
> It isas if it is trying to be abstract andbe non committal on the 
> protocol.
>
> SocketChannel and SeverSocketChannel have been up to this point 
> synonymous with TCP. The underlying protocol
>
> is TCP so I think it could be stated explicitly.
>
>
Yes, there is a slight inconsistency there in that specific paragraph, 
because it is a general

one about java.net.StandardProtocolFamily. I might change "support 
network communication using TCP/IP"

to "support network communication using TCP and UDP*". *Since SCTP is 
not part of Java SE, I don't

think we need to refer to it here.
**

> ? UnixDomainSocketAddress spec
>
>
> 41* <p> An <a id="unnamed"></a><i>unnamed</i> {@code 
> UnixDomainSocketAddress} has
>
> 42* an empty path. The local address of a Unix domain socket that is 
> automatically
>
> 43* bound will be unnamed.
>
>
> WRT UnixDomainSocketAddress an unnamed address equates to an empty 
> PATH ? rather than a null PATH
>
>
> But an empty Path is significant, asper PATH spec stated below
>
>
> A Path is considered to be an /empty path/ if it consists solely of 
> one name element that is empty.
>
> Accessing a file using an /empty path/ is equivalent to accessing the 
> default directory of the file system.
>
>
I don't see an issue with the above comment. The last sentence 
describing file behavior for empty

paths is not directly relevant to sockets.


> Also this infers that auto bound sockets have unnamed representations. 
> However, this is at variance with ServerSocketChannel
>
>
> *234* @apiNote*
>
> *235* Binding a channel to a <i>Unix Domain</i> socket creates a file 
> corresponding to*
>
> *236* the file path in the {@link UnixDomainSocketAddress}. This file 
> persists*
>
> *237* after the channel is closed, and must be removed before another 
> socket can*
>
> *238* bind to the same name. Binding to an address that is 
> automatically assigned*
>
> *239* will create a unique file in some system temporary location. The 
> associated*
>
> *240* socket file also persists after the channel is closed. Its name 
> can be*
>
> *241* obtained from the channel's local socket address.*
>
>
> There are also some contractions in the following with 
> UnixDomainSocketAddress spec, in that auto binding for
>
> SocketChannel and ServerSocketChannel are distinct procedures:
>
>
> *361* If a Unix domain {@link SocketChannel} is automatically bound by 
> connecting it*
>
> *362* without calling {@link SocketChannel#bind(SocketAddress) bind} 
> first, then its*
>
> *363* address is <i>unnamed</i>; it has an empty path field, and 
> therefore has no*
>
> *364* associated file in the file-system. Explicitly binding a {@code 
> SocketChannel}*
>
> *365* to any unnamed address has the same effect.*
>
> *366* <p>*
>
> *367* If a Unix domain {@link ServerSocketChannel} is automatically 
> bound by passing a*
>
> *368* {@code null} address to one of the {@link 
> ServerSocketChannel#bind(SocketAddress) bind}*
>
> *369* methods, the channel is bound to a unique name in the temporary 
> directory identified*
>
> *370* by the {@code "java.io.tmpdir"} system property. The exact 
> pathname can be obtained by*
>
> *371* calling {@link ServerSocketChannel#getLocalAddress() 
> getLocalAddress} after bind returns.*
>
> *372* It is an error to bind a {@code ServerSocketChannel} to an 
> unnamed address.*
>
>
> Why not auto bind SocketChannel using similar mechanism to that of 
> ServerSocketChannel, and have the unnamed
>
> address to explicitly represent an unbound SocketChannel?
>
>
>
This is the distinction I referred to above with respect to "implicit 
binding" and "automatic assignment"
of addresses. It's just a difference between Unix domain and Inet, where 
we need to support unnamed

client sockets for Unix domain, but the concept does not make sense for 
server sockets.


> In any case all is hunky dory when considering SocketChannel 
> encapsulating a unix domain socket in the context of
>
> sending and receiving data. However, unix domain sockets have 
> additional capabilities and functionality which distinguish
>
> them from a TCP counterpart.This is in terms of sending file 
> descriptors and capabilities. This is significant functionality.
>
> So much so, that it should be at least considered they are represented 
> bytheir own distinct set of abstractions, analogous to SctpChannel.
>
> This could be done through either subclassing {Server} SocketChannel 
> or placing a relevant set of abstractions at the same
>
> in the SelectableChannel hierarchy
>
>
> I think having a separate set of abstractions for ?unix domain 
> sockets? would make them easier to use, allow for easier specification 
> of the additional
>
> functionality and behaviour andleave SocketChannel and 
> ServerSocketChannel synonymous with the TCP protocol.
>
>
> As such, an abstraction such as:
>
> * LocalChannel, LocalServerChannel, or
>
> * LocalSocketChannel, LocalServerSocketChannel, or
>
> * LocalDomainChannel, LocalDomainServerChannel
>
> Are worth considering
>
>
I have done some prototyping of support for capabilities like that. But, 
it's out of scope for this
JEP, and we can look at it afterwards. For what it's worth, it is 
possible to implement sending and
receiving of channels without requiring any new API types.
>
> Some motivating factors for suggesting a separate set of api 
> abstractionsare:
>
>
> It will more clearly separate out the underlying protocol domains.
>
>
> Provides clearer and cleaner semantics. For example, other than the 
> fact that a TCP socket
>
> and Unix domain socket exhibit stream behaviour, a Unix domain socket 
> can exhibit
>
> different behaviour in connection establishment, send/receive behaviour;
>
> they not subject to flow control etc, and may exhibit different 
> reliability semantics,
>
> in that it is possible for a sender to flood a receiver.
>
>
> They have a different access model in being subject to OS level 
> permission on the OS filesystem.
>
> This leads to different bind behaviour, connect behaviour - different 
> causes for IOException or SocketException.
>
> They use a different ?socket address? namespace i.e. the filesystem 
> name space.
>
> Close behaviour is different - requires additional explicit management 
> of the socket domain
>
> namespace in the filesystem.
>
>
> Having separate API abstractions allows for specific descriptions and 
> specification for those abstractions
>
> Having a separate abstraction will provide cleaner, more precise and 
> clearer semantics for a Unix domain channel abstraction
>
> Allows for clearer, more precise specification definition,and 
> developer documentation, avoiding possible ambiguities.
>
>
>
> Eliminates the StandardProtocolFamily extensions
>
> BUT will require addition of openLocalChannel/openLocalServerChannel 
> methods to SelectorProvider
>
>
> Eliminates socket method and throwing of UnSupportedException
>
>
> backward compatibility in the API - SocketChannel and 
> ServerSocketChannel remain as they are
>
> and the new functionality is defined in a new distinct set of abstractions
>
>
> Allows for easier integrationof the additional features and 
> functionality associated with unix domain sockets,
>
> for example, the passing of file descriptors, or capability exchanges 
> (sendCredential, receiveCredential).
>
>
> File descriptor passing can be easily included in a separate 
> abstraction (e.g. LocalChannel), with additional methods,
>
> such as** sendFD(FileDescriptorn fd)**, ** receiveFD(FileDescriptor 
> fd) ** provided for the purpose or even with
>
> an overloaded send and receive method.
>
> Thus, avoiding the need to retrofit such extended functionality into 
> the existing SocketChannel api.
>
> Of course, alternatively such functionality could be supported by a 
> mediating utility abstraction, such as 
> FileDescriptorExchanger::send(FileDescriptor, 
> SocketChannel)FileDescriptorExchanger::recv(FileDescriptor, 
> SocketChannel) for the purpose of exchanging file descriptors.
>
>
> In short a Unix domain socket is a different functional abstraction, 
> which has different and extended behaviour.
>
> As such defining a separate API abstraction provides for clear, 
> unambiguous behaviour, making easier to use, and
>
> allowing for easier integration of additional extended behaviour.
>
>
>

I'm not convinced that new abstractions are needed other than the bare 
minimum for representing
the new address type and protocol family etc. You can take a look at the 
prototype i did for sending & receiving channels

in the sandbox (sendchannels branch). It is implemented as 
SocketOption<Channel>. Setting the option

is used for sending a channel and getting it receives one. There's a bit 
more to it than that, but new APIs are not
required. And, in any case, this is out of scope for this JEP anyway.


Thanks

Michael


> best regards
> Mark
>
> ------------------------------------------------------------------------
> *From:* nio-dev <nio-dev-bounces at openjdk.java.net> on behalf of 
> Michael McMahon <michael.x.mcmahon at oracle.com>
> *Sent:* Thursday 18 June 2020 14:31
> *To:* nio-dev at openjdk.java.net <nio-dev at openjdk.java.net>
> *Subject:* RFR 8245194: Unix domain socket channel implementation
>
> Hi,
>
> I'd like to start the review for JEP-380 (Unix Domain Socket Channels) 
> [1]. The first and smaller part of this JEP (8241305: Add protocol 
> specific factory creation methods to SocketChannel and 
> ServerSocketChannel) has already been integrated in JDK 15. This main 
> part of the JEP will hopefully be targeted to 16 under this bugid 
> (8245194 Unix Domain socket channel implementation [3])
>
> The full webrev [4] touches a lot of files, so I have put the public 
> API change in a separate webrev at [5] and there is a specdiff at [6].
>
> The implementation, while it touches a lot of files, is mostly about 
> re-factoring the existing SocketImpl and ServerSocketImpl 
> implementation classes into separate Inet and Unix variants, along 
> with the new implementation code for Unix domain.
>
> Comments welcome on either the implementation or the API, although I 
> would like to concentrate on the API to start with as I expect the 
> review will have several iterations.
>
> Regards,
>
> Michael.
>
>
> [1] https://openjdk.java.net/jeps/380 <https://openjdk.java.net/jeps/380>
>
> [2] https://bugs.openjdk.java.net/browse/JDK-8241305 
> <https://bugs.openjdk.java.net/browse/JDK-8241305>
>
> [3] https://bugs.openjdk.java.net/browse/JDK-8245194 
> <https://bugs.openjdk.java.net/browse/JDK-8245194>
>
> [4] http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.1/
>
> [5] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.1/
>
> [6] 
> http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.1/overview-summary.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200703/7c2c8da8/attachment-0001.htm>

From michael.x.mcmahon at oracle.com  Fri Jul  3 11:42:00 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 3 Jul 2020 12:42:00 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <e1b16b78-dfa6-73c8-273b-21f89265a413@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <e1b16b78-dfa6-73c8-273b-21f89265a413@oracle.com>
Message-ID: <8e6c045a-5b04-ed67-748a-42dcab7835a7@oracle.com>

Hi Alan

I realise I didn't reply to this on the list. Thanks for the review.
I have proposed the CSR as you suggested with the initial text changes 
you suggest,
but not the API change moving UnixDomainSocketAddress to java.net.

We can resolve that question before finalizing the CSR.

Thanks again,

Michael

On 29/06/2020 10:46, Alan Bateman wrote:
> On 18/06/2020 15:31, Michael McMahon wrote:
>>
>> Hi,
>>
>> I'd like to start the review for JEP-380 (Unix Domain Socket 
>> Channels) [1]. The first and smaller part of this JEP (8241305: Add 
>> protocol specific factory creation methods to SocketChannel and 
>> ServerSocketChannel) has already been integrated in JDK 15. This main 
>> part of the JEP will hopefully be targeted to 16 under this bugid 
>> (8245194 Unix Domain socket channel implementation [3])
>>
>> The full webrev [4] touches a lot of files, so I have put the public 
>> API change in a separate webrev at [5] and there is a specdiff at [6].
>>
>> The implementation, while it touches a lot of files, is mostly about 
>> re-factoring the existing SocketImpl and ServerSocketImpl 
>> implementation classes into separate Inet and Unix variants, along 
>> with the new implementation code for Unix domain.
>>
>> Comments welcome on either the implementation or the API, although I 
>> would like to concentrate on the API to start with as I expect the 
>> review will have several iterations.
>>
> I've read through the API and overall I think this looks very good and 
> fits well with the existing API. Splitting this into API + 
> implementation for review purposes is good as I agree the 
> implementation changes will go through several review cycles.
>
> The javadoc updates to SocketChannel/ServerSocketChannel are good 
> except connect(SocketAddress) where it creates an inconsistency with 
> "For Internet Protocol channels ..." and "For Unix Domain channels". 
> The existing API tries to talk about the channel's socket so I think 
> connect should follow this (you've got it right in the other 
> additions, or rather than I didn't spot other inconsistencies).? 
> Another place with the same issue is the wording in in 
> java.net.NetworkPermission.
>
> SelectorProvider::inheritedChannel. "... where the inherited channel 
> represents a Unix domain socket" is consistent with the existing 
> javadoc but it inconsistent with the javadoc in the channel classes 
> where they create a socket channel "for an Internet protocol sockets". 
> So if you are okay with it, I think we should adjust the existing 
> inheritedChannel javadoc as part of this.
>
> UnixDomainPrincipal and the ExtendedSocketOption.SO_PEERCRED socket 
> option looks good. UnixDomainPrincipal will probably need to link to 
> the description for Unix domain sockets.
>
> I'm in two minds on adding UnixDomainSocketAddress to 
> java.nio.channels as it could be argued that it should be in java.net 
> with SocketAddress and InetSocketAddress. I need to think a bit more 
> about this one.
>
> I have a few comments on the updates to the package description but 
> overall I think the API additions are in good shape. Okay with me if 
> you want get the CSR submitted (propose rather and finalize) and then 
> update it later when it is final.
>
> -Alan
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200703/581f19f6/attachment.htm>

From me at yawk.at  Fri Jul  3 11:58:25 2020
From: me at yawk.at (Jonas Konrad)
Date: Fri, 3 Jul 2020 13:58:25 +0200
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
Message-ID: <e5b82425-37ed-cc3c-2269-cf3a2c2624ee@yawk.at>

Hi,

 From looking at the JEP I can see that implementing abstract domain 
sockets (i.e. paths that start with a NUL byte) is not a goal at the 
moment. From what I can tell, with the current API this would fail in 
the Path.of step, which throws an Exception for NUL characters in the 
Path. Maybe this check should be moved up to UnixDomainSocketAddress, or 
at least be documented in some way ? right now the fact that this fails 
looks more accidental.

- Jonas

On 6/18/20 4:31 PM, Michael McMahon wrote:
> Hi,
> 
> I'd like to start the review for JEP-380 (Unix Domain Socket Channels) 
> [1]. The first and smaller part of this JEP (8241305: Add protocol 
> specific factory creation methods to SocketChannel and 
> ServerSocketChannel) has already been integrated in JDK 15. This main 
> part of the JEP will hopefully be targeted to 16 under this bugid 
> (8245194 Unix Domain socket channel implementation [3])
> 
> The full webrev [4] touches a lot of files, so I have put the public API 
> change in a separate webrev at [5] and there is a specdiff at [6].
> 
> The implementation, while it touches a lot of files, is mostly about 
> re-factoring the existing SocketImpl and ServerSocketImpl implementation 
> classes into separate Inet and Unix variants, along with the new 
> implementation code for Unix domain.
> 
> Comments welcome on either the implementation or the API, although I 
> would like to concentrate on the API to start with as I expect the 
> review will have several iterations.
> 
> Regards,
> 
> Michael.
> 
> 
> [1] https://openjdk.java.net/jeps/380
> 
> [2] https://bugs.openjdk.java.net/browse/JDK-8241305
> 
> [3] https://bugs.openjdk.java.net/browse/JDK-8245194
> 
> [4] http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.1/
> 
> [5] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.1/
> 
> [6] 
> http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.1/overview-summary.html
> 

From Alan.Bateman at oracle.com  Sat Jul  4 15:11:58 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 4 Jul 2020 16:11:58 +0100
Subject: 8219014: (bf) Add absolute bulk put methods which accept a source
 Buffer
In-Reply-To: <F9A2E585-E3EB-4CB6-9D05-16DEBB77A8C2@oracle.com>
References: <5F6F4823-8B99-48DB-9B7A-44CF2A3DADBD@oracle.com>
 <45CBA103-32F0-46FE-8444-35828A990733@oracle.com>
 <87wo8ti01g.fsf@oldenburg2.str.redhat.com>
 <824238F5-D399-4088-A1AA-A9AC8321577F@oracle.com>
 <87eev1hwxa.fsf@oldenburg2.str.redhat.com>
 <EC834E5F-0E3E-456B-BBA2-457F81098D3D@oracle.com>
 <8736bhhvst.fsf@oldenburg2.str.redhat.com>
 <6B7BB465-EA1F-4763-8E2D-927B71EADFC6@oracle.com>
 <87imjsxk4j.fsf@oldenburg2.str.redhat.com>
 <65CD68C6-07A8-4811-B4FD-0F1277DA8697@oracle.com>
 <87y2rfi8og.fsf@oldenburg2.str.redhat.com>
 <805C5BDD-C826-4C61-A9A8-11656FD71267@oracle.com>
 <E9FEFC18-1E31-4F18-8F89-720253F53D62@oracle.com>
 <35F64B3C-BC66-4788-8200-44AB7E321845@oracle.com>
 <18AEADCF-52D6-4D6D-9F07-976631CE96CB@oracle.com>
 <FF5E6B44-0F40-464E-B9FD-E30D2A5DD912@oracle.com>
 <F9A2E585-E3EB-4CB6-9D05-16DEBB77A8C2@oracle.com>
Message-ID: <e5384ae5-fb3d-8c72-ea6b-5c4c53a1628c@oracle.com>

On 02/07/2020 21:15, Brian Burkhalter wrote:
> I have attached a specdiff to the CSR [1].
>
This method does overlap a bit with MemorySegment but I think it's 
okay.? The wording in the javadoc is good. The existing absolute 
operations use "index" rather than "offset" so I think you'll have to 
rename the parameters for the source region to "srcIndex" and 
"srcLength" to keep the naming consistent.

Minor nit in the patch is that the naming for the parameters to the 
non-public putBuffer are also inconsistent. Also would be good to keep 
the style @param/@return/@throws consistent rather brining a different 
style into the templates.

There aren't any tests in webrev.02, are these coming for the next round?

-Alan

From brian.burkhalter at oracle.com  Mon Jul  6 15:55:35 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 6 Jul 2020 08:55:35 -0700
Subject: 8219014: (bf) Add absolute bulk put methods which accept a source
 Buffer
In-Reply-To: <e5384ae5-fb3d-8c72-ea6b-5c4c53a1628c@oracle.com>
References: <5F6F4823-8B99-48DB-9B7A-44CF2A3DADBD@oracle.com>
 <45CBA103-32F0-46FE-8444-35828A990733@oracle.com>
 <87wo8ti01g.fsf@oldenburg2.str.redhat.com>
 <824238F5-D399-4088-A1AA-A9AC8321577F@oracle.com>
 <87eev1hwxa.fsf@oldenburg2.str.redhat.com>
 <EC834E5F-0E3E-456B-BBA2-457F81098D3D@oracle.com>
 <8736bhhvst.fsf@oldenburg2.str.redhat.com>
 <6B7BB465-EA1F-4763-8E2D-927B71EADFC6@oracle.com>
 <87imjsxk4j.fsf@oldenburg2.str.redhat.com>
 <65CD68C6-07A8-4811-B4FD-0F1277DA8697@oracle.com>
 <87y2rfi8og.fsf@oldenburg2.str.redhat.com>
 <805C5BDD-C826-4C61-A9A8-11656FD71267@oracle.com>
 <E9FEFC18-1E31-4F18-8F89-720253F53D62@oracle.com>
 <35F64B3C-BC66-4788-8200-44AB7E321845@oracle.com>
 <18AEADCF-52D6-4D6D-9F07-976631CE96CB@oracle.com>
 <FF5E6B44-0F40-464E-B9FD-E30D2A5DD912@oracle.com>
 <F9A2E585-E3EB-4CB6-9D05-16DEBB77A8C2@oracle.com>
 <e5384ae5-fb3d-8c72-ea6b-5c4c53a1628c@oracle.com>
Message-ID: <BC6C019D-80BD-400C-827F-863E3887CB40@oracle.com>


> On Jul 4, 2020, at 8:11 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 02/07/2020 21:15, Brian Burkhalter wrote:
>> I have attached a specdiff to the CSR [1].
>> 
> This method does overlap a bit with MemorySegment but I think it's okay.  The wording in the javadoc is good. The existing absolute operations use "index" rather than "offset" so I think you'll have to rename the parameters for the source region to "srcIndex" and "srcLength" to keep the naming consistent.
> 
> Minor nit in the patch is that the naming for the parameters to the non-public putBuffer are also inconsistent. Also would be good to keep the style @param/@return/@throws consistent rather brining a different style into the templates.

Will improve as suggested.

> There aren't any tests in webrev.02, are these coming for the next round?

Yes. I wanted to ascertain that this would go forward before doing more work.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200706/7eed4da4/attachment.htm>

From brian.burkhalter at oracle.com  Mon Jul  6 23:54:31 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 6 Jul 2020 16:54:31 -0700
Subject: RFR: JDK-8232092: (fs) Files::isWritable returns false on a
 writeable root directory (win)
In-Reply-To: <DM6PR21MB1289FC1464E6BA2F0248761CF5690@DM6PR21MB1289.namprd21.prod.outlook.com>
References: <DM6PR21MB1289FC1464E6BA2F0248761CF5690@DM6PR21MB1289.namprd21.prod.outlook.com>
Message-ID: <3472705B-C732-4474-B44D-731165634110@oracle.com>

Hello Nikola,

I added to the issue [1] a link [2] to the archive of your message.

I should note that the discussion should ideally be conducted on nio-dev [3] as the topic pertains to that subcomponent.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8232092
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067594.html
[3] https://mail.openjdk.java.net/mailman/listinfo/nio-dev

> On Jul 6, 2020, at 2:59 PM, Nikola Grcevski <Nikola.Grcevski at microsoft.com> wrote:
> 
> I was asked to help look into JDK-8232092 by Christian Stein (the bug reporter), and since I don't have an OpenJDK account yet I'm sharing my findings on the issue here. I looked into two separate issues that might cause FileSystemProvider.checkAccess to return an incorrect result as reported. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200706/427a0ec1/attachment.htm>

From chris.hegarty at oracle.com  Tue Jul  7 14:18:40 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 7 Jul 2020 15:18:40 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
Message-ID: <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>



> On 18 Jun 2020, at 15:31, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> ..
> 
> Comments welcome on either the implementation or the API, although I would like to concentrate on the API to start with as I expect the review will have several iterations.
> 
First off, this looks very good. And it seems that you have been able to weave Unix domain sockets into the existing API quite nicely.

My initial reaction to seeing verbiage like "Internet protocol socket? and ?unix domain socket?, is how does one know what type of socket channel one has if passed an unbound channel? I wonder if a SocketChannel::protocolFamily method is worth adding? It could be used and linked to from some of the verbiage elsewhere to tighten the spec. There could also be some tie in here with inheritedChannel - if the protocol family is retrievable.

I would be good to explicitly mention that UnixDomainSocketAddress.of?(String), allows an empty path string. There is a definition of _unnamed_ in UDSA - which I like. But later in the channel?s spec the wording ?with an empty path? is used. I wonder if we could use _unnamed_ in such places, and link back to its definition? 

I had some comments on the implementation and spec for the serial proxy of UDSA, but I just pushed these to the sandbox [1], so they?ll be incorporated in the next iteration.

-Chris.

[1] https://hg.openjdk.java.net/jdk/sandbox/rev/481b20e7e9b2

From Nikola.Grcevski at microsoft.com  Tue Jul  7 14:19:30 2020
From: Nikola.Grcevski at microsoft.com (Nikola Grcevski)
Date: Tue, 7 Jul 2020 14:19:30 +0000
Subject: RFR: JDK-8232092: (fs) Files::isWritable returns false on a
 writeable root directory (win)
In-Reply-To: <3472705B-C732-4474-B44D-731165634110@oracle.com>
References: <DM6PR21MB1289FC1464E6BA2F0248761CF5690@DM6PR21MB1289.namprd21.prod.outlook.com>
 <3472705B-C732-4474-B44D-731165634110@oracle.com>
Message-ID: <BYAPR21MB12854DE44B9C960B496480F8F5660@BYAPR21MB1285.namprd21.prod.outlook.com>

Thanks Brian! Let's continue the discussion here in nio-dev.

From: Brian Burkhalter <brian.burkhalter at oracle.com>
Sent: July 6, 2020 7:55 PM
To: Nikola Grcevski <Nikola.Grcevski at microsoft.com>
Cc: core-libs-dev at openjdk.java.net; nio-dev <nio-dev at openjdk.java.net>
Subject: Re: RFR: JDK-8232092: (fs) Files::isWritable returns false on a writeable root directory (win)

Hello Nikola,

I added to the issue [1] a link [2] to the archive of your message.

I should note that the discussion should ideally be conducted on nio-dev [3] as the topic pertains to that subcomponent.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8232092<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8232092&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C550709f099f240dbe0cc08d822085170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637296766409163591&sdata=xS8t7Nh1IcVPBPRN%2BJtYXRrEdve853SejEvQSD3jWho%3D&reserved=0>
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067594.html<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fcore-libs-dev%2F2020-July%2F067594.html&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C550709f099f240dbe0cc08d822085170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637296766409163591&sdata=kLPZvpyirS6imHUPOpMqatWIgkuC2cBfvEj6InPt0%2Fk%3D&reserved=0>
[3] https://mail.openjdk.java.net/mailman/listinfo/nio-dev<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fmailman%2Flistinfo%2Fnio-dev&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C550709f099f240dbe0cc08d822085170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637296766409173590&sdata=enCQWKT4JEL2nOeX0laM3CW7U9rAShHRKeYykS7mEhI%3D&reserved=0>


On Jul 6, 2020, at 2:59 PM, Nikola Grcevski <Nikola.Grcevski at microsoft.com<mailto:Nikola.Grcevski at microsoft.com>> wrote:

I was asked to help look into JDK-8232092 by Christian Stein (the bug reporter), and since I don't have an OpenJDK account yet I'm sharing my findings on the issue here. I looked into two separate issues that might cause FileSystemProvider.checkAccess to return an incorrect result as reported.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200707/9d4ac202/attachment.htm>

From michael.x.mcmahon at oracle.com  Wed Jul  8 10:07:30 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 8 Jul 2020 11:07:30 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
Message-ID: <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>

Hi Chris

Thanks for the review.

On 07/07/2020 15:18, Chris Hegarty wrote:
>
>> On 18 Jun 2020, at 15:31, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
>> ..
>>
>> Comments welcome on either the implementation or the API, although I would like to concentrate on the API to start with as I expect the review will have several iterations.
>>
> First off, this looks very good. And it seems that you have been able to weave Unix domain sockets into the existing API quite nicely.
>
> My initial reaction to seeing verbiage like "Internet protocol socket? and ?unix domain socket?, is how does one know what type of socket channel one has if passed an unbound channel? I wonder if a SocketChannel::protocolFamily method is worth adding? It could be used and linked to from some of the verbiage elsewhere to tighten the spec. There could also be some tie in here with inheritedChannel - if the protocol family is retrievable.
I did consider that question and had concluded that testing the type of 
the SocketAddress returned by getLocalAddress() would suffice for this. 
But, you're right that does not work for unbound channels. I'll add this 
to the API for now (for SocketChannel and ServerSocketChannel in the 
sandbox), to see what it looks like. Perhaps, for consistency it should 
be added to DatagramChannel too?
> I would be good to explicitly mention that UnixDomainSocketAddress.of?(String), allows an empty path string. There is a definition of _unnamed_ in UDSA - which I like. But later in the channel?s spec the wording ?with an empty path? is used. I wonder if we could use _unnamed_ in such places, and link back to its definition?
Ok
> I had some comments on the implementation and spec for the serial proxy of UDSA, but I just pushed these to the sandbox [1], so they?ll be incorporated in the next iteration.

Great, thanks


Michael


> -Chris.
>
> [1] https://hg.openjdk.java.net/jdk/sandbox/rev/481b20e7e9b2

From Roger.Riggs at oracle.com  Wed Jul  8 16:16:23 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 8 Jul 2020 12:16:23 -0400
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
Message-ID: <57bf19f8-5fda-ef71-ef4e-a5fc4b4ad503@oracle.com>

Hi Michael,

Not a complete review but something in changeset below caught my eye.
For the serialization proxy class name, use the shortest string possible.
No need to waste space in the serialization stream with a long name.
The serialization proxy class name is already qualified by the enclosing 
class name.
In java.time we use the class name 'Ser'.

Regards, Roger

On 7/8/20 6:07 AM, Michael McMahon wrote:
>
>
>> -Chris.
>>
>> [1] https://hg.openjdk.java.net/jdk/sandbox/rev/481b20e7e9b2


From chris.hegarty at oracle.com  Thu Jul  9 14:09:53 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 9 Jul 2020 15:09:53 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <57bf19f8-5fda-ef71-ef4e-a5fc4b4ad503@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <57bf19f8-5fda-ef71-ef4e-a5fc4b4ad503@oracle.com>
Message-ID: <4EDFBF11-D339-4E27-9068-67105E16E42A@oracle.com>



> On 8 Jul 2020, at 17:16, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> ..
> The serialization proxy class name is already qualified by the enclosing class name.
> In java.time we use the class name 'Ser?.

Yeah, I thought of that too, but then, somewhat lazily, opted for the shorter-than-current but longer-than-Ser name. `Ser` is better.

-Chris.

From chris.hegarty at oracle.com  Thu Jul  9 14:14:05 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 9 Jul 2020 15:14:05 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
Message-ID: <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>



> On 8 Jul 2020, at 11:07, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> 
>> ...
>> 
>> My initial reaction to seeing verbiage like "Internet protocol socket? and ?unix domain socket?, is how does one know what type of socket channel one has if passed an unbound channel? I wonder if a SocketChannel::protocolFamily method is worth adding? It could be used and linked to from some of the verbiage elsewhere to tighten the spec. There could also be some tie in here with inheritedChannel - if the protocol family is retrievable.
> I did consider that question and had concluded that testing the type of the SocketAddress returned by getLocalAddress() would suffice for this. But, you're right that does not work for unbound channels. I'll add this to the API for now (for SocketChannel and ServerSocketChannel in the sandbox), to see what it looks like. Perhaps, for consistency it should be added to DatagramChannel too?

That works for me.

What is the signature of this method? `Optional<ProtocolFamily> protocolFamily()` - or something else? If not optional ( or null ), then what is the family of a channel created with the no-args open method? We had some offline discussion about UNSPEC, and if we add this method then it could be a reason to add an UNSPEC StandardProtocolFamily.

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200709/2cd4b2bb/attachment.htm>

From daniel.fuchs at oracle.com  Thu Jul  9 15:27:11 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 Jul 2020 16:27:11 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
Message-ID: <2b1f071f-9e3c-6886-0e23-8c926fa2cc45@oracle.com>

Hi Chris,

I haven't reviewed the code yet, just pouncing on your comment ;-)

On 09/07/2020 15:14, Chris Hegarty wrote:
> What is the signature of this method? `Optional<ProtocolFamily> 
> protocolFamily()` - or something else? If not optional ( or null ), then 
> what is the family of a channel created with the no-args open method? We 
> had some offline discussion about UNSPEC, and if we add this method then 
> it could be a reason to add an UNSPEC StandardProtocolFamily.
> 

UNSPEC would be clearly unsuitable in this case.

The protocolFamily should be either INET or INET6 depending on whether 
the underlying socket that was created is IPv4 only or dual.

best regards,

-- daniel

From michael.x.mcmahon at oracle.com  Fri Jul 10 10:25:56 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 10 Jul 2020 11:25:56 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
Message-ID: <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>


On 09/07/2020 15:14, Chris Hegarty wrote:
>
>
>> On 8 Jul 2020, at 11:07, Michael McMahon 
>> <michael.x.mcmahon at oracle.com <mailto:michael.x.mcmahon at oracle.com>> 
>> wrote:
>>
>>> ...
>>>
>>> My initial reaction to seeing verbiage like "Internet protocol 
>>> socket? and ?unix domain socket?, is how does one know what type of 
>>> socket channel one has if passed an unbound channel? I wonder if a 
>>> SocketChannel::protocolFamily method is worth adding? It could be 
>>> used and linked to from some of the verbiage elsewhere to tighten 
>>> the spec. There could also be some tie in here with inheritedChannel 
>>> - if the protocol family is retrievable.
>> I did consider that question and had concluded that testing the type 
>> of the SocketAddress returned by getLocalAddress() would suffice for 
>> this. But, you're right that does not work for unbound channels. I'll 
>> add this to the API for now (for SocketChannel and 
>> ServerSocketChannel in the sandbox), to see what it looks like. 
>> Perhaps, for consistency it should be added to DatagramChannel too?
>
> That works for me.
>
> What is the signature of this method? `Optional<ProtocolFamily> 
> protocolFamily()` - or something else? If not optional ( or null ), 
> then what is the family of a channel created with the no-args open 
> method? We had some offline discussion about UNSPEC, and if we add 
> this method then it could be a reason to add an UNSPEC 
> StandardProtocolFamily.
>
"public ProtocolFamily getProtocolFamily()"

I think a channel will always have a ProtocolFamily. So, it shouldn't 
need to be Optional<>

The value on the no-args call depends on the preferIPv4Stack setting. 
INET if set INET6 if not,
depending on which of IPv4/IPv6 are supported obviously. Do you think 
all of this would need
to be documented explicitly?

Michael

> -Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200710/b431be9e/attachment.htm>

From ecki at zusammenkunft.net  Fri Jul 10 10:33:12 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 10 Jul 2020 10:33:12 +0000
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>,
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
Message-ID: <AM6PR03MB4389083117882AC9E2FFD23AFF650@AM6PR03MB4389.eurprd03.prod.outlook.com>

I like the protocolFamily addition. Should it allow to differentiate between IPv6 socket bound to ipv4 address or in case of wildcard bound dual stack? (I sometimes had the desire in the path to see what the prefer Option and network libraries closed to use, so you can for example know if the listening shows up in socketstat as v4 or v6 address.


--
http://bernd.eckenfels.net
________________________________
Von: nio-dev <nio-dev-retn at openjdk.java.net> im Auftrag von Michael McMahon <michael.x.mcmahon at oracle.com>
Gesendet: Friday, July 10, 2020 12:25:56 PM
An: Chris Hegarty <chris.hegarty at oracle.com>
Cc: nio-dev <nio-dev at openjdk.java.net>
Betreff: Re: RFR 8245194: Unix domain socket channel implementation



On 09/07/2020 15:14, Chris Hegarty wrote:


On 8 Jul 2020, at 11:07, Michael McMahon <michael.x.mcmahon at oracle.com<mailto:michael.x.mcmahon at oracle.com>> wrote:

...

My initial reaction to seeing verbiage like "Internet protocol socket? and ?unix domain socket?, is how does one know what type of socket channel one has if passed an unbound channel? I wonder if a SocketChannel::protocolFamily method is worth adding? It could be used and linked to from some of the verbiage elsewhere to tighten the spec. There could also be some tie in here with inheritedChannel - if the protocol family is retrievable.
I did consider that question and had concluded that testing the type of the SocketAddress returned by getLocalAddress() would suffice for this. But, you're right that does not work for unbound channels. I'll add this to the API for now (for SocketChannel and ServerSocketChannel in the sandbox), to see what it looks like. Perhaps, for consistency it should be added to DatagramChannel too?

That works for me.

What is the signature of this method? `Optional<ProtocolFamily> protocolFamily()` - or something else? If not optional ( or null ), then what is the family of a channel created with the no-args open method? We had some offline discussion about UNSPEC, and if we add this method then it could be a reason to add an UNSPEC StandardProtocolFamily.


"public ProtocolFamily getProtocolFamily()"

I think a channel will always have a ProtocolFamily. So, it shouldn't need to be Optional<>

The value on the no-args call depends on the preferIPv4Stack setting. INET if set INET6 if not,
depending on which of IPv4/IPv6 are supported obviously. Do you think all of this would need
to be documented explicitly?

Michael

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200710/22eab040/attachment-0001.htm>

From chris.hegarty at oracle.com  Fri Jul 10 11:02:18 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 10 Jul 2020 12:02:18 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
Message-ID: <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>



> On 10 Jul 2020, at 11:25, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
>> ...
> "public ProtocolFamily getProtocolFamily()"
> 
> I think a channel will always have a ProtocolFamily. So, it shouldn't need to be Optional<>
> 
> The value on the no-args call depends on the preferIPv4Stack setting. INET if set INET6 if not,
> depending on which of IPv4/IPv6 are supported obviously. Do you think all of this would need
> to be documented explicitly?
> 
I would not specify or document any of this, other than; "Internet protocol socket? is one of INET or INET6, and ?unix domain socket? is UNIX. I think that is sufficient.

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200710/397595e6/attachment.htm>

From michael.x.mcmahon at oracle.com  Fri Jul 10 15:20:05 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 10 Jul 2020 16:20:05 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <57bf19f8-5fda-ef71-ef4e-a5fc4b4ad503@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <57bf19f8-5fda-ef71-ef4e-a5fc4b4ad503@oracle.com>
Message-ID: <1fc76315-70fe-96db-5b40-9618934c184d@oracle.com>

Hi Roger

Yes, good point. I will incorporate that in the next round.

Thanks

Michael

On 08/07/2020 17:16, Roger Riggs wrote:
> Hi Michael,
>
> Not a complete review but something in changeset below caught my eye.
> For the serialization proxy class name, use the shortest string possible.
> No need to waste space in the serialization stream with a long name.
> The serialization proxy class name is already qualified by the 
> enclosing class name.
> In java.time we use the class name 'Ser'.
>
> Regards, Roger
>
> On 7/8/20 6:07 AM, Michael McMahon wrote:
>>
>>
>>> -Chris.
>>>
>>> [1] https://hg.openjdk.java.net/jdk/sandbox/rev/481b20e7e9b2
>

From stefan.reich.maker.of.eye at googlemail.com  Sat Jul 11 09:36:55 2020
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sat, 11 Jul 2020 11:36:55 +0200
Subject: File locking supported on all platforms?
Message-ID: <CAC2-jLHDQXse9e8pQwV6sTHuqMUoopFjpHgb=Nnq+ZHNUe5UsA@mail.gmail.com>

Hi,

a quick question regarding file locks in Java. I seem to remember reading
somewhere that this feature isn't guaranteed to work on all platforms.
However, I can now find no mention of that e.g. here
<https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileLock.html>.

The page does list that numerous special assumptions may fail, for example
that programs which *don't* lock a file are prevented from changing it when
it is locked by another program.

However, I only care about the basic feature, namely that one local file
cannot be locked by two Java programs at once and will cause one of them to
throw an exception.

Is this guaranteed to work everywhere?

Many greetings
Stefan

-- 
Stefan Reich
BotCompany.de // Java-based operating systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200711/3bd805fb/attachment.htm>

From me at yawk.at  Sat Jul 11 09:44:55 2020
From: me at yawk.at (Jonas Konrad)
Date: Sat, 11 Jul 2020 11:44:55 +0200
Subject: File locking supported on all platforms?
In-Reply-To: <CAC2-jLHDQXse9e8pQwV6sTHuqMUoopFjpHgb=Nnq+ZHNUe5UsA@mail.gmail.com>
References: <CAC2-jLHDQXse9e8pQwV6sTHuqMUoopFjpHgb=Nnq+ZHNUe5UsA@mail.gmail.com>
Message-ID: <80e8368e-cf3e-2ba7-e7ff-70408739023b@yawk.at>

Hey,

Some file systems on Linux, eg old NFS, do not support locking at all.

- Jonas

On 7/11/20 11:36 AM, Stefan Reich wrote:
> Hi,
> 
> a quick question regarding?file locks in Java. I seem to remember 
> reading somewhere that this feature isn't guaranteed to work on all 
> platforms. However, I can now find no mention of that e.g. here 
> <https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileLock.html>.
> 
> The page does list that numerous special assumptions may fail, for 
> example that programs which /don't/ lock a file are prevented from 
> changing it when it is locked by another program.
> 
> However, I only care about the basic feature, namely that one local file 
> cannot be locked by two Java programs at once and will cause one of them 
> to throw an exception.
> 
> Is this guaranteed to work everywhere?
> 
> Many greetings
> Stefan
> 
> -- 
> Stefan Reich
> BotCompany.de // Java-based operating systems

From stefan.reich.maker.of.eye at googlemail.com  Sat Jul 11 09:47:36 2020
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sat, 11 Jul 2020 11:47:36 +0200
Subject: File locking supported on all platforms?
In-Reply-To: <80e8368e-cf3e-2ba7-e7ff-70408739023b@yawk.at>
References: <CAC2-jLHDQXse9e8pQwV6sTHuqMUoopFjpHgb=Nnq+ZHNUe5UsA@mail.gmail.com>
 <80e8368e-cf3e-2ba7-e7ff-70408739023b@yawk.at>
Message-ID: <CAC2-jLHwkVzHQcNtsF5xhjA-4=dnLn-wiYb3=9XMNwdmagTohQ@mail.gmail.com>

Hi Jonas,

what would happen if I try to lock a file on these platforms? Can I
reliably detect this case? That would already help a lot.

The use case is ensuring a database's consistency which I now do over a
socket protocol, but file locks would be faster and more reliable.

Stefan

On Sat, 11 Jul 2020 at 11:45, Jonas Konrad <me at yawk.at> wrote:

> Hey,
>
> Some file systems on Linux, eg old NFS, do not support locking at all.
>
> - Jonas
>
> On 7/11/20 11:36 AM, Stefan Reich wrote:
> > Hi,
> >
> > a quick question regarding file locks in Java. I seem to remember
> > reading somewhere that this feature isn't guaranteed to work on all
> > platforms. However, I can now find no mention of that e.g. here
> > <
> https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileLock.html
> >.
> >
> > The page does list that numerous special assumptions may fail, for
> > example that programs which /don't/ lock a file are prevented from
> > changing it when it is locked by another program.
> >
> > However, I only care about the basic feature, namely that one local file
> > cannot be locked by two Java programs at once and will cause one of them
> > to throw an exception.
> >
> > Is this guaranteed to work everywhere?
> >
> > Many greetings
> > Stefan
> >
> > --
> > Stefan Reich
> > BotCompany.de // Java-based operating systems
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200711/ea916cf9/attachment.htm>

From me at yawk.at  Sat Jul 11 10:10:05 2020
From: me at yawk.at (Jonas Konrad)
Date: Sat, 11 Jul 2020 12:10:05 +0200
Subject: File locking supported on all platforms?
In-Reply-To: <CAC2-jLHwkVzHQcNtsF5xhjA-4=dnLn-wiYb3=9XMNwdmagTohQ@mail.gmail.com>
References: <CAC2-jLHDQXse9e8pQwV6sTHuqMUoopFjpHgb=Nnq+ZHNUe5UsA@mail.gmail.com>
 <80e8368e-cf3e-2ba7-e7ff-70408739023b@yawk.at>
 <CAC2-jLHwkVzHQcNtsF5xhjA-4=dnLn-wiYb3=9XMNwdmagTohQ@mail.gmail.com>
Message-ID: <e6d6f4ec-49cc-da45-efe6-41cc1b92ecbd@yawk.at>

I think it should just fail silently / without error, that's what fcntl 
does at least. I'm not sure if there's a good way to determine whether 
locking will actually work.

- Jonas

On 7/11/20 11:47 AM, Stefan Reich wrote:
> Hi Jonas,
> 
> what would happen if I try to lock a file on these platforms? Can I 
> reliably detect this case? That would already help a lot.
> 
> The use case is ensuring a database's consistency which I now do over a 
> socket protocol, but file locks would be faster and more reliable.
> 
> Stefan
> 
> On Sat, 11 Jul 2020 at 11:45, Jonas Konrad <me at yawk.at 
> <mailto:me at yawk.at>> wrote:
> 
>     Hey,
> 
>     Some file systems on Linux, eg old NFS, do not support locking at all.
> 
>     - Jonas
> 
>     On 7/11/20 11:36 AM, Stefan Reich wrote:
>      > Hi,
>      >
>      > a quick question regarding?file locks in Java. I seem to remember
>      > reading somewhere that this feature isn't guaranteed to work on all
>      > platforms. However, I can now find no mention of that e.g. here
>      >
>     <https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileLock.html>.
>      >
>      > The page does list that numerous special assumptions may fail, for
>      > example that programs which /don't/ lock a file are prevented from
>      > changing it when it is locked by another program.
>      >
>      > However, I only care about the basic feature, namely that one
>     local file
>      > cannot be locked by two Java programs at once and will cause one
>     of them
>      > to throw an exception.
>      >
>      > Is this guaranteed to work everywhere?
>      >
>      > Many greetings
>      > Stefan
>      >
>      > --
>      > Stefan Reich
>      > BotCompany.de // Java-based operating systems
> 
> 
> 
> -- 
> Stefan Reich
> BotCompany.de // Java-based operating systems

From stefan.reich.maker.of.eye at googlemail.com  Sat Jul 11 10:13:40 2020
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sat, 11 Jul 2020 12:13:40 +0200
Subject: File locking supported on all platforms?
In-Reply-To: <e6d6f4ec-49cc-da45-efe6-41cc1b92ecbd@yawk.at>
References: <CAC2-jLHDQXse9e8pQwV6sTHuqMUoopFjpHgb=Nnq+ZHNUe5UsA@mail.gmail.com>
 <80e8368e-cf3e-2ba7-e7ff-70408739023b@yawk.at>
 <CAC2-jLHwkVzHQcNtsF5xhjA-4=dnLn-wiYb3=9XMNwdmagTohQ@mail.gmail.com>
 <e6d6f4ec-49cc-da45-efe6-41cc1b92ecbd@yawk.at>
Message-ID: <CAC2-jLEHovzdJPm=8Ch_g8ppHVxxV6RzTxpeWpFQWfuNJS6fSA@mail.gmail.com>

Hmm that's what I feared. So to be really sure I should do an actual test.
Maybe I can get away with doing two locks on the same file within one JVM
for testing the feature? I should try that.

Thanks

On Sat, 11 Jul 2020 at 12:10, Jonas Konrad <me at yawk.at> wrote:

> I think it should just fail silently / without error, that's what fcntl
> does at least. I'm not sure if there's a good way to determine whether
> locking will actually work.
>
> - Jonas
>
> On 7/11/20 11:47 AM, Stefan Reich wrote:
> > Hi Jonas,
> >
> > what would happen if I try to lock a file on these platforms? Can I
> > reliably detect this case? That would already help a lot.
> >
> > The use case is ensuring a database's consistency which I now do over a
> > socket protocol, but file locks would be faster and more reliable.
> >
> > Stefan
> >
> > On Sat, 11 Jul 2020 at 11:45, Jonas Konrad <me at yawk.at
> > <mailto:me at yawk.at>> wrote:
> >
> >     Hey,
> >
> >     Some file systems on Linux, eg old NFS, do not support locking at
> all.
> >
> >     - Jonas
> >
> >     On 7/11/20 11:36 AM, Stefan Reich wrote:
> >      > Hi,
> >      >
> >      > a quick question regarding file locks in Java. I seem to remember
> >      > reading somewhere that this feature isn't guaranteed to work on
> all
> >      > platforms. However, I can now find no mention of that e.g. here
> >      >
> >     <
> https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileLock.html
> >.
> >      >
> >      > The page does list that numerous special assumptions may fail, for
> >      > example that programs which /don't/ lock a file are prevented from
> >      > changing it when it is locked by another program.
> >      >
> >      > However, I only care about the basic feature, namely that one
> >     local file
> >      > cannot be locked by two Java programs at once and will cause one
> >     of them
> >      > to throw an exception.
> >      >
> >      > Is this guaranteed to work everywhere?
> >      >
> >      > Many greetings
> >      > Stefan
> >      >
> >      > --
> >      > Stefan Reich
> >      > BotCompany.de // Java-based operating systems
> >
> >
> >
> > --
> > Stefan Reich
> > BotCompany.de // Java-based operating systems
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200711/650970ad/attachment.htm>

From fweimer at redhat.com  Sat Jul 11 12:51:32 2020
From: fweimer at redhat.com (Florian Weimer)
Date: Sat, 11 Jul 2020 14:51:32 +0200
Subject: File locking supported on all platforms?
In-Reply-To: <80e8368e-cf3e-2ba7-e7ff-70408739023b@yawk.at> (Jonas Konrad's
 message of "Sat, 11 Jul 2020 11:44:55 +0200")
References: <CAC2-jLHDQXse9e8pQwV6sTHuqMUoopFjpHgb=Nnq+ZHNUe5UsA@mail.gmail.com>
 <80e8368e-cf3e-2ba7-e7ff-70408739023b@yawk.at>
Message-ID: <87wo3ausdn.fsf@oldenburg2.str.redhat.com>

* Jonas Konrad:

> Some file systems on Linux, eg old NFS, do not support locking at all.

I don't think it's as bleak as that.  Many NFS deployments have a
working lock manager.  In other cases, NFS is just used to export
non-shared storage to a machine, so it's sufficient if the machine
performs local lock management only (which does not require the NFS
locking protocol).

> Hmm that's what I feared. So to be really sure I should do an actual
> test. Maybe I can get away with doing two locks on the same file
> within one JVM for testing the feature? I should try that.

That's one of the cases that do NOT work as expected on Linux because
that's how POSIX file locking is required to behave (for all file
systems, including local ones).

If OpenJDK switched to Linux OFD locks, behavior would be closer to the
expected one.

Thanks,
Florian


From me at yawk.at  Sat Jul 11 14:13:27 2020
From: me at yawk.at (Jonas Konrad)
Date: Sat, 11 Jul 2020 16:13:27 +0200
Subject: File locking supported on all platforms?
In-Reply-To: <CAC2-jLEHovzdJPm=8Ch_g8ppHVxxV6RzTxpeWpFQWfuNJS6fSA@mail.gmail.com>
References: <CAC2-jLHDQXse9e8pQwV6sTHuqMUoopFjpHgb=Nnq+ZHNUe5UsA@mail.gmail.com>
 <80e8368e-cf3e-2ba7-e7ff-70408739023b@yawk.at>
 <CAC2-jLHwkVzHQcNtsF5xhjA-4=dnLn-wiYb3=9XMNwdmagTohQ@mail.gmail.com>
 <e6d6f4ec-49cc-da45-efe6-41cc1b92ecbd@yawk.at>
 <CAC2-jLEHovzdJPm=8Ch_g8ppHVxxV6RzTxpeWpFQWfuNJS6fSA@mail.gmail.com>
Message-ID: <d06b746d-bdb2-371e-eb79-8d72aedfc591@yawk.at>

I asked around and apparently fcntl locking can be idempotent in the 
same process at least for some fs, so locking twice in the same jvm may 
not error even on an fs that does support locks.

- Jonas

On 7/11/20 12:13 PM, Stefan Reich wrote:
> Hmm that's what I feared. So to be really sure I should do an actual 
> test. Maybe?I can get away with doing two locks on the same file within 
> one JVM for testing the feature? I should try that.
> 
> Thanks
> 
> On Sat, 11 Jul 2020 at 12:10, Jonas Konrad <me at yawk.at 
> <mailto:me at yawk.at>> wrote:
> 
>     I think it should just fail silently / without error, that's what fcntl
>     does at least. I'm not sure if there's a good way to determine whether
>     locking will actually work.
> 
>     - Jonas
> 
>     On 7/11/20 11:47 AM, Stefan Reich wrote:
>      > Hi Jonas,
>      >
>      > what would happen if I try to lock a file on these platforms? Can I
>      > reliably detect this case? That would already help a lot.
>      >
>      > The use case is ensuring a database's consistency which I now do
>     over a
>      > socket protocol, but file locks would be faster and more reliable.
>      >
>      > Stefan
>      >
>      > On Sat, 11 Jul 2020 at 11:45, Jonas Konrad <me at yawk.at
>     <mailto:me at yawk.at>
>      > <mailto:me at yawk.at <mailto:me at yawk.at>>> wrote:
>      >
>      >? ? ?Hey,
>      >
>      >? ? ?Some file systems on Linux, eg old NFS, do not support
>     locking at all.
>      >
>      >? ? ?- Jonas
>      >
>      >? ? ?On 7/11/20 11:36 AM, Stefan Reich wrote:
>      >? ? ? > Hi,
>      >? ? ? >
>      >? ? ? > a quick question regarding?file locks in Java. I seem to
>     remember
>      >? ? ? > reading somewhere that this feature isn't guaranteed to
>     work on all
>      >? ? ? > platforms. However, I can now find no mention of that e.g.
>     here
>      >? ? ? >
>      >   
>      ?<https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileLock.html>.
>      >? ? ? >
>      >? ? ? > The page does list that numerous special assumptions may
>     fail, for
>      >? ? ? > example that programs which /don't/ lock a file are
>     prevented from
>      >? ? ? > changing it when it is locked by another program.
>      >? ? ? >
>      >? ? ? > However, I only care about the basic feature, namely that one
>      >? ? ?local file
>      >? ? ? > cannot be locked by two Java programs at once and will
>     cause one
>      >? ? ?of them
>      >? ? ? > to throw an exception.
>      >? ? ? >
>      >? ? ? > Is this guaranteed to work everywhere?
>      >? ? ? >
>      >? ? ? > Many greetings
>      >? ? ? > Stefan
>      >? ? ? >
>      >? ? ? > --
>      >? ? ? > Stefan Reich
>      >? ? ? > BotCompany.de // Java-based operating systems
>      >
>      >
>      >
>      > --
>      > Stefan Reich
>      > BotCompany.de // Java-based operating systems
> 
> 
> 
> -- 
> Stefan Reich
> BotCompany.de // Java-based operating systems

From michael.x.mcmahon at oracle.com  Mon Jul 13 11:41:36 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 13 Jul 2020 12:41:36 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <AM6PR03MB4389083117882AC9E2FFD23AFF650@AM6PR03MB4389.eurprd03.prod.outlook.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <AM6PR03MB4389083117882AC9E2FFD23AFF650@AM6PR03MB4389.eurprd03.prod.outlook.com>
Message-ID: <d2dd375b-3516-ced5-aa69-b58e9fc1c38d@oracle.com>

INET6 effectively means IPv4 or IPv6 and the protocol family is set at 
socket creation,
before binding. So, I don't think it would be possible to do that.

Michael.

On 10/07/2020 11:33, Bernd Eckenfels wrote:
> I like the protocolFamily addition. Should it allow to differentiate 
> between IPv6 socket bound to ipv4 address or in case of wildcard bound 
> dual stack? (I sometimes had the desire in the path to see what the 
> prefer Option and network libraries closed to use, so you can for 
> example know if the listening shows up in socketstat as v4 or v6 address.
>
>
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* nio-dev <nio-dev-retn at openjdk.java.net> im Auftrag von Michael 
> McMahon <michael.x.mcmahon at oracle.com>
> *Gesendet:* Friday, July 10, 2020 12:25:56 PM
> *An:* Chris Hegarty <chris.hegarty at oracle.com>
> *Cc:* nio-dev <nio-dev at openjdk.java.net>
> *Betreff:* Re: RFR 8245194: Unix domain socket channel implementation
>
>
> On 09/07/2020 15:14, Chris Hegarty wrote:
>>
>>
>>> On 8 Jul 2020, at 11:07, Michael McMahon 
>>> <michael.x.mcmahon at oracle.com <mailto:michael.x.mcmahon at oracle.com>> 
>>> wrote:
>>>
>>>> ...
>>>>
>>>> My initial reaction to seeing verbiage like "Internet protocol 
>>>> socket? and ?unix domain socket?, is how does one know what type of 
>>>> socket channel one has if passed an unbound channel? I wonder if a 
>>>> SocketChannel::protocolFamily method is worth adding? It could be 
>>>> used and linked to from some of the verbiage elsewhere to tighten 
>>>> the spec. There could also be some tie in here with 
>>>> inheritedChannel - if the protocol family is retrievable.
>>> I did consider that question and had concluded that testing the type 
>>> of the SocketAddress returned by getLocalAddress() would suffice for 
>>> this. But, you're right that does not work for unbound channels. 
>>> I'll add this to the API for now (for SocketChannel and 
>>> ServerSocketChannel in the sandbox), to see what it looks like. 
>>> Perhaps, for consistency it should be added to DatagramChannel too?
>>
>> That works for me.
>>
>> What is the signature of this method? `Optional<ProtocolFamily> 
>> protocolFamily()` - or something else? If not optional ( or null ), 
>> then what is the family of a channel created with the no-args open 
>> method? We had some offline discussion about UNSPEC, and if we add 
>> this method then it could be a reason to add an UNSPEC 
>> StandardProtocolFamily.
>>
> "public ProtocolFamily getProtocolFamily()"
>
> I think a channel will always have a ProtocolFamily. So, it shouldn't 
> need to be Optional<>
>
> The value on the no-args call depends on the preferIPv4Stack setting. 
> INET if set INET6 if not,
> depending on which of IPv4/IPv6 are supported obviously. Do you think 
> all of this would need
> to be documented explicitly?
>
> Michael
>
>> -Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200713/03f10698/attachment.htm>

From Alan.Bateman at oracle.com  Tue Jul 14 09:31:42 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Jul 2020 10:31:42 +0100
Subject: File locking supported on all platforms?
In-Reply-To: <d06b746d-bdb2-371e-eb79-8d72aedfc591@yawk.at>
References: <CAC2-jLHDQXse9e8pQwV6sTHuqMUoopFjpHgb=Nnq+ZHNUe5UsA@mail.gmail.com>
 <80e8368e-cf3e-2ba7-e7ff-70408739023b@yawk.at>
 <CAC2-jLHwkVzHQcNtsF5xhjA-4=dnLn-wiYb3=9XMNwdmagTohQ@mail.gmail.com>
 <e6d6f4ec-49cc-da45-efe6-41cc1b92ecbd@yawk.at>
 <CAC2-jLEHovzdJPm=8Ch_g8ppHVxxV6RzTxpeWpFQWfuNJS6fSA@mail.gmail.com>
 <d06b746d-bdb2-371e-eb79-8d72aedfc591@yawk.at>
Message-ID: <14de9030-ac70-89ee-8cc9-c07b57979ed1@oracle.com>

On 11/07/2020 15:13, Jonas Konrad wrote:
> I asked around and apparently fcntl locking can be idempotent in the 
> same process at least for some fs, so locking twice in the same jvm 
> may not error even on an fs that does support locks.
You should get an OverlappingFileLockException in that case.? As a 
reminder, the file locking API is intended for coordinating access with 
other programs, it cannot be used to coordinate access to a file in the 
same VM.

I see NFS is mentioned in the discussion. Yes, there can be issues in 
NFS environments but if the lock daemon is not running on the remote NFS 
server then I would expect the lock or tryLock methods to throw an 
IOException "No locks available".

-Alan

From me at yawk.at  Tue Jul 14 09:59:01 2020
From: me at yawk.at (Jonas Konrad)
Date: Tue, 14 Jul 2020 11:59:01 +0200
Subject: File locking supported on all platforms?
In-Reply-To: <14de9030-ac70-89ee-8cc9-c07b57979ed1@oracle.com>
References: <CAC2-jLHDQXse9e8pQwV6sTHuqMUoopFjpHgb=Nnq+ZHNUe5UsA@mail.gmail.com>
 <80e8368e-cf3e-2ba7-e7ff-70408739023b@yawk.at>
 <CAC2-jLHwkVzHQcNtsF5xhjA-4=dnLn-wiYb3=9XMNwdmagTohQ@mail.gmail.com>
 <e6d6f4ec-49cc-da45-efe6-41cc1b92ecbd@yawk.at>
 <CAC2-jLEHovzdJPm=8Ch_g8ppHVxxV6RzTxpeWpFQWfuNJS6fSA@mail.gmail.com>
 <d06b746d-bdb2-371e-eb79-8d72aedfc591@yawk.at>
 <14de9030-ac70-89ee-8cc9-c07b57979ed1@oracle.com>
Message-ID: <0f57d3a7-3671-c459-a923-3068f1cd90c5@yawk.at>

> I see NFS is mentioned in the discussion. Yes, there can be issues in 
> NFS environments but if the lock daemon is not running on the remote NFS 
> server then I would expect the lock or tryLock methods to throw an 
> IOException "No locks available".

Nope, it'll just grant the lock twice. Linux fcntl will not return an 
error so I don't see how the JDK could detect this case anyway

- Jonas

From Alan.Bateman at oracle.com  Tue Jul 14 10:53:11 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Jul 2020 11:53:11 +0100
Subject: File locking supported on all platforms?
In-Reply-To: <0f57d3a7-3671-c459-a923-3068f1cd90c5@yawk.at>
References: <CAC2-jLHDQXse9e8pQwV6sTHuqMUoopFjpHgb=Nnq+ZHNUe5UsA@mail.gmail.com>
 <80e8368e-cf3e-2ba7-e7ff-70408739023b@yawk.at>
 <CAC2-jLHwkVzHQcNtsF5xhjA-4=dnLn-wiYb3=9XMNwdmagTohQ@mail.gmail.com>
 <e6d6f4ec-49cc-da45-efe6-41cc1b92ecbd@yawk.at>
 <CAC2-jLEHovzdJPm=8Ch_g8ppHVxxV6RzTxpeWpFQWfuNJS6fSA@mail.gmail.com>
 <d06b746d-bdb2-371e-eb79-8d72aedfc591@yawk.at>
 <14de9030-ac70-89ee-8cc9-c07b57979ed1@oracle.com>
 <0f57d3a7-3671-c459-a923-3068f1cd90c5@yawk.at>
Message-ID: <742df8af-a463-376a-3640-97f8c1500aa2@oracle.com>

On 14/07/2020 10:59, Jonas Konrad wrote:
>> I see NFS is mentioned in the discussion. Yes, there can be issues in 
>> NFS environments but if the lock daemon is not running on the remote 
>> NFS server then I would expect the lock or tryLock methods to throw 
>> an IOException "No locks available".
>
> Nope, it'll just grant the lock twice. Linux fcntl will not return an 
> error so I don't see how the JDK could detect this case anyway
Do you have an example to explain what you mean? The lock and tryLock 
methods should throw OverlappingFileLockException if you attempt to lock 
a region that overlaps with a region already held in same VM. So you 
shouldn't see a second call to fnctl.

-Alan

From me at yawk.at  Tue Jul 14 10:56:19 2020
From: me at yawk.at (Jonas Konrad)
Date: Tue, 14 Jul 2020 12:56:19 +0200
Subject: File locking supported on all platforms?
In-Reply-To: <742df8af-a463-376a-3640-97f8c1500aa2@oracle.com>
References: <CAC2-jLHDQXse9e8pQwV6sTHuqMUoopFjpHgb=Nnq+ZHNUe5UsA@mail.gmail.com>
 <80e8368e-cf3e-2ba7-e7ff-70408739023b@yawk.at>
 <CAC2-jLHwkVzHQcNtsF5xhjA-4=dnLn-wiYb3=9XMNwdmagTohQ@mail.gmail.com>
 <e6d6f4ec-49cc-da45-efe6-41cc1b92ecbd@yawk.at>
 <CAC2-jLEHovzdJPm=8Ch_g8ppHVxxV6RzTxpeWpFQWfuNJS6fSA@mail.gmail.com>
 <d06b746d-bdb2-371e-eb79-8d72aedfc591@yawk.at>
 <14de9030-ac70-89ee-8cc9-c07b57979ed1@oracle.com>
 <0f57d3a7-3671-c459-a923-3068f1cd90c5@yawk.at>
 <742df8af-a463-376a-3640-97f8c1500aa2@oracle.com>
Message-ID: <0a179f13-caf3-5ef7-b25f-91b8c161b174@yawk.at>

Sorry I meant when locking the same file from two processes. When the 
file is on an nfs without lock daemon and two processes on different 
machines try to lock it at the same time both will succeed without 
error. There is no "No locks available" error.

- Jonas

On 7/14/20 12:53 PM, Alan Bateman wrote:
> On 14/07/2020 10:59, Jonas Konrad wrote:
>>> I see NFS is mentioned in the discussion. Yes, there can be issues in 
>>> NFS environments but if the lock daemon is not running on the remote 
>>> NFS server then I would expect the lock or tryLock methods to throw 
>>> an IOException "No locks available".
>>
>> Nope, it'll just grant the lock twice. Linux fcntl will not return an 
>> error so I don't see how the JDK could detect this case anyway
> Do you have an example to explain what you mean? The lock and tryLock 
> methods should throw OverlappingFileLockException if you attempt to lock 
> a region that overlaps with a region already held in same VM. So you 
> shouldn't see a second call to fnctl.
> 
> -Alan

From Alan.Bateman at oracle.com  Tue Jul 14 15:03:09 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Jul 2020 16:03:09 +0100
Subject: RFR: JDK-8232092: (fs) Files::isWritable returns false on a
 writeable root directory (win)
In-Reply-To: <DM6PR21MB1289FC1464E6BA2F0248761CF5690@DM6PR21MB1289.namprd21.prod.outlook.com>
References: <DM6PR21MB1289FC1464E6BA2F0248761CF5690@DM6PR21MB1289.namprd21.prod.outlook.com>
Message-ID: <aea874d5-8804-c5a7-a0ab-a6aa69883ef6@oracle.com>

On 06/07/2020 22:59, Nikola Grcevski wrote:
> :
>
> The first issue seems related to substituted directories with volumes, or virtual drives on Windows. The problem happens if the Windows GetVolumePathNameW API is called with a virtual drive letter in the path, causing the API to return ERROR_INVALID_PARAMETER or error code 87.
Thanks for the mail on this. I think the new information here is that 
Christian may be using "subst" or some other mechanism. He did mention 
"virtual" but it wasn't clear what type of volume that was. This may be 
enough to duplicate the problem. It is likely this is part of a large 
piece of work to support subst, something the file system implementation 
has never fully supported.

-Alan

From Nikola.Grcevski at microsoft.com  Tue Jul 14 15:28:57 2020
From: Nikola.Grcevski at microsoft.com (Nikola Grcevski)
Date: Tue, 14 Jul 2020 15:28:57 +0000
Subject: RFR: JDK-8232092: (fs) Files::isWritable returns false on a
 writeable root directory (win)
In-Reply-To: <aea874d5-8804-c5a7-a0ab-a6aa69883ef6@oracle.com>
References: <DM6PR21MB1289FC1464E6BA2F0248761CF5690@DM6PR21MB1289.namprd21.prod.outlook.com>
 <aea874d5-8804-c5a7-a0ab-a6aa69883ef6@oracle.com>
Message-ID: <DM6PR21MB1289A5228A1981F9ACB65EBBF5610@DM6PR21MB1289.namprd21.prod.outlook.com>

Thanks for looking into this Alan. I'm more than happy to help in any way possible to implement proper support for virtual drives on Windows. I was thinking about running the jtreg class library tests on a virtual drive and see how many failures we get.

Based on the JBS update from Christian, it seems the other virtual drive failure was a third-party software issue.

Cheers,
Nikola

-----Original Message-----
From: Alan Bateman <Alan.Bateman at oracle.com> 
Sent: July 14, 2020 11:03 AM
To: Nikola Grcevski <Nikola.Grcevski at microsoft.com>; nio-dev <nio-dev at openjdk.java.net>
Subject: Re: RFR: JDK-8232092: (fs) Files::isWritable returns false on a writeable root directory (win)

On 06/07/2020 22:59, Nikola Grcevski wrote:
> :
>
> The first issue seems related to substituted directories with volumes, or virtual drives on Windows. The problem happens if the Windows GetVolumePathNameW API is called with a virtual drive letter in the path, causing the API to return ERROR_INVALID_PARAMETER or error code 87.
Thanks for the mail on this. I think the new information here is that Christian may be using "subst" or some other mechanism. He did mention "virtual" but it wasn't clear what type of volume that was. This may be enough to duplicate the problem. It is likely this is part of a large piece of work to support subst, something the file system implementation has never fully supported.

-Alan

From michael.x.mcmahon at oracle.com  Thu Jul 16 14:49:47 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 16 Jul 2020 15:49:47 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
Message-ID: <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>

Hi,

I have updated the API webrev [1], the complete webrev [2] and the 
specdiff [3] from the review comments so far.

I've also made a couple of other small API changes I should mention.

- the package-info for java.nio.channels now refers to the 
"java.net.preferIPv4Stack" property which has always affected its 
behavior, but which wasn't clearly documented.

- the temporary directory used by automatically bound Unix Domain 
ServerSocketChannels can be overridden using the "java.nio.tempdir" 
system property. This is to overcome the problem where ${java.io.tmpdir} 
points to a directory whose name is too long for Unix domain sockets.

Comments welcome.

Thanks,
Michael.

[1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.4/

[2] http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.4/

[3] 
http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.4/overview-summary.html


From daniel.fuchs at oracle.com  Thu Jul 16 15:28:57 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 Jul 2020 16:28:57 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
Message-ID: <69e05ea7-2b04-e043-ea82-821371a6d5a1@oracle.com>

Hi Michael,

The package-info for java.net has a section about Addresses.
Given that UnixDomainSocketAddress is now in class in the
java.net package, I wonder if, for clarity, that section
(or the Socket section that comes after) should be updated
to say that java.net sockets only support the
Internet Protocol, and point to java.nio.channels for
channels supporting the UNIX domain protocol?

Maybe a sub-section "About UNIX domain" - similar to "About IPv6",
in either one of these two sections?

http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.4/java.base/java/net/package-summary.html

Similarly - maybe UnixDomainSocketAddress could have an @see
pointing to the SocketChannel and ServerSocketChannel?


In 
http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.4/java.base/java/nio/channels/ServerSocketChannel.html
two args bind method:

"SecurityException: If a security manager has been installed and its 
checkListen method denies the operation for an Internet protocol socket 
address or NetPermission("allowUnixDomainChannels") when the socket 
address is a Unix domain socket address"

It sounds like some words (verb?) are missing just before NetPermission?
Possibly a comma or semicolon after "for an Internet protocol socket 
address" could make the parsing easier too.


In 
http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.4/java.base/java/nio/channels/SocketChannel.html
open(SocketAddress) method:

"UnresolvedAddressException - If the given remote -a-d-d-r-e-s-s- is an 
InetSocketAddress that is not fully resolved"

For consistency with the description of the method where "remote 
address" is used, I would not remove the "address" word here.

For the bind(SocketAddress), the @throws SecurityException clause seems
to have the same issue than outlined above for ServerSocketChannel.

Otherwise the spec look good to me. Nice job of implementing the
feature with such a small API surface!

best regards

-- daniel

On 16/07/2020 15:49, Michael McMahon wrote:
> Hi,
> 
> I have updated the API webrev [1], the complete webrev [2] and the 
> specdiff [3] from the review comments so far.
> 
> I've also made a couple of other small API changes I should mention.
> 
> - the package-info for java.nio.channels now refers to the 
> "java.net.preferIPv4Stack" property which has always affected its 
> behavior, but which wasn't clearly documented.
> 
> - the temporary directory used by automatically bound Unix Domain 
> ServerSocketChannels can be overridden using the "java.nio.tempdir" 
> system property. This is to overcome the problem where ${java.io.tmpdir} 
> points to a directory whose name is too long for Unix domain sockets.
> 
> Comments welcome.
> 
> Thanks,
> Michael.
> 
> [1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.4/
> 
> [2] http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.4/
> 
> [3] 
> http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.4/overview-summary.html 
> 
> 


From conor.cleary at oracle.com  Thu Jul 16 16:03:46 2020
From: conor.cleary at oracle.com (Conor Cleary)
Date: Thu, 16 Jul 2020 17:03:46 +0100
Subject: RFR[8246707]: '(sc) SocketChannel.read/write throws
 AsynchronousCloseException on closed channel'
Message-ID: <3ab365e5-ea96-aee1-bbb3-a24d301e5169@oracle.com>

Hi all,

Could someone please take a look at my webrev for JDK-8246707 '(sc) 
SocketChannel.read/write throws AsynchronousCloseException on closed 
channel'?

This fix addresses an issue where an AsynchronousCloseException was 
being thrown instead of a ChannelClosedException when 
SocketChannel.write() is called on a /closed/ SocketChannel.


bug: https://bugs.openjdk.java.net/browse/JDK-8246707
webrev: 
http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246707/webrevs/webrev.02/


Regards,
Conor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200716/1af7f13e/attachment.htm>

From daniel.fuchs at oracle.com  Thu Jul 16 16:26:13 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 Jul 2020 17:26:13 +0100
Subject: RFR[8246707]: '(sc) SocketChannel.read/write throws
 AsynchronousCloseException on closed channel'
In-Reply-To: <3ab365e5-ea96-aee1-bbb3-a24d301e5169@oracle.com>
References: <3ab365e5-ea96-aee1-bbb3-a24d301e5169@oracle.com>
Message-ID: <5fbce220-800c-d79b-7654-bd091c6f1fc5@oracle.com>

Hi Conor,

Ah! I see it now. Sneaky throwing in the finally clause :-)
You will need a test. Did you forget to `hg add` it before
calling webrev?

best regards,

-- daniel


On 16/07/2020 17:03, Conor Cleary wrote:
> Hi all,
> 
> Could someone please take a look at my webrev for JDK-8246707 '(sc) 
> SocketChannel.read/write throws AsynchronousCloseException on closed 
> channel'?
> 
> This fix addresses an issue where an AsynchronousCloseException was 
> being thrown instead of a ChannelClosedException when 
> SocketChannel.write() is called on a /closed/ SocketChannel.
> 
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8246707
> webrev: 
> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246707/webrevs/webrev.02/
> 
> 
> Regards,
> Conor
> 


From Alan.Bateman at oracle.com  Thu Jul 16 16:26:28 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 Jul 2020 17:26:28 +0100
Subject: RFR[8246707]: '(sc) SocketChannel.read/write throws
 AsynchronousCloseException on closed channel'
In-Reply-To: <3ab365e5-ea96-aee1-bbb3-a24d301e5169@oracle.com>
References: <3ab365e5-ea96-aee1-bbb3-a24d301e5169@oracle.com>
Message-ID: <6075867e-ef0f-86e4-4849-1341aa3d68f8@oracle.com>

On 16/07/2020 17:03, Conor Cleary wrote:
>
> Hi all,
>
> Could someone please take a look at my webrev for JDK-8246707 '(sc) 
> SocketChannel.read/write throws AsynchronousCloseException on closed 
> channel'?
>
> This fix addresses an issue where an AsynchronousCloseException was 
> being thrown instead of a ChannelClosedException when 
> SocketChannel.write() is called on a /closed/ SocketChannel.
>
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8246707
> webrev: 
> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246707/webrevs/webrev.02/
>
Thanks for this, this was an oversight when this code was refactored. 
It's not technically wrong to throw a sub-class of 
ChannelClosedException but AsynchronousCloseException could indeed be 
confusion. Are you planning to include a test? It may be that some of 
the existing tests to check that ChannelClosedException is thrown on a 
closed channel could be updated to check that the exception is not 
AsynchronousCloseException.

As regards the change, then for consistency I would like to see 
blockingRead, blockingWriteFully and sendOutOfBandData also call 
ensureOpenAndConnected before checking the blocking mode. That will keep 
them consistent with read/write. Also the beginWrite(true) in 
blockingWriteFully should be inside the try block rather than outside 
(okay if that is done as a separate issue if needed but it's all in the 
same area so I mention it here).

-Alan.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200716/c670e265/attachment.htm>

From chris.hegarty at oracle.com  Thu Jul 16 19:08:01 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 16 Jul 2020 20:08:01 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
Message-ID: <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>



> On 16 Jul 2020, at 15:49, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> ...
> 
> [1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.4/
> 
> [2] http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.4/
> 
> [3] http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.4/overview-summary.html
> 
1) I?d still like to see "an unnamed UnixDomainSocketAddress" used instead of "UnixDomainSocketAddress with an empty path? - since we have a nice definition of _unnamed_ already.

2) I wonder if we can add the following definitions:

  ?channel for an Internet protocol socket?  - channel::getProtocolFamily returns one of INET or INET6

  ?channel for a Unix domain socket? - channel::getProtocolFamily returns UNIX

-Chris.

From michael.x.mcmahon at oracle.com  Fri Jul 17 10:57:45 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 17 Jul 2020 11:57:45 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <69e05ea7-2b04-e043-ea82-821371a6d5a1@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <69e05ea7-2b04-e043-ea82-821371a6d5a1@oracle.com>
Message-ID: <148bba6c-8a41-8ea4-7915-3da01eeb4e6c@oracle.com>

Hi Daniel,

Thanks for the review.

On 16/07/2020 16:28, Daniel Fuchs wrote:
> Hi Michael,
>
> The package-info for java.net has a section about Addresses.
> Given that UnixDomainSocketAddress is now in class in the
> java.net package, I wonder if, for clarity, that section
> (or the Socket section that comes after) should be updated
> to say that java.net sockets only support the
> Internet Protocol, and point to java.nio.channels for
> channels supporting the UNIX domain protocol?
>
> Maybe a sub-section "About UNIX domain" - similar to "About IPv6",
> in either one of these two sections?
>

I'm not sure. The package level docs for java.net don't mention
SocketAddress or InetSocketAddress either. Maybe it should have a paragraph
like that but I feel it's out of scope for this work.

I notice that there is no equivalent explanation relating to 
StandardProtocolFamily
which is also only used in NIO. Maybe both of these could be addressed 
in another
doc update?

> http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.4/java.base/java/net/package-summary.html 
>
>
> Similarly - maybe UnixDomainSocketAddress could have an @see
> pointing to the SocketChannel and ServerSocketChannel?
>

I agree that is a simple change, which would be useful.

>
> In 
> http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.4/java.base/java/nio/channels/ServerSocketChannel.html
> two args bind method:
>
> "SecurityException: If a security manager has been installed and its 
> checkListen method denies the operation for an Internet protocol 
> socket address or NetPermission("allowUnixDomainChannels") when the 
> socket address is a Unix domain socket address"
>
> It sounds like some words (verb?) are missing just before NetPermission?
> Possibly a comma or semicolon after "for an Internet protocol socket 
> address" could make the parsing easier too.
>
How about rewording as:

 ???? * @throws? SecurityException
 ???? *????????? If a security manager has been installed and its {@link
 ???? *????????? SecurityManager#checkListen checkListen} method denies
 ???? *????????? the operation for an <i>Internet protocol</i> socket 
address,
 ???? *????????? or for a <i>Unix domain</i> socket address if it denies
 ???? *????????? {@link NetPermission}{@code("allowUnixDomainChannels")}.

>
> In 
> http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.4/java.base/java/nio/channels/SocketChannel.html
> open(SocketAddress) method:
>
> "UnresolvedAddressException - If the given remote -a-d-d-r-e-s-s- is 
> an InetSocketAddress that is not fully resolved"
>
> For consistency with the description of the method where "remote 
> address" is used, I would not remove the "address" word here.
>

Right. That should not have been removed.

> For the bind(SocketAddress), the @throws SecurityException clause seems
> to have the same issue than outlined above for ServerSocketChannel.
>

Yes, I suggest the same wording as above

> Otherwise the spec look good to me. Nice job of implementing the
> feature with such a small API surface!
>

Excellent. Thanks for the review

Michael

> best regards
>
> -- daniel
>
>

From michael.x.mcmahon at oracle.com  Fri Jul 17 14:57:38 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 17 Jul 2020 15:57:38 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
Message-ID: <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>

Hi Chris,

Thanks for the review.

On 16/07/2020 20:08, Chris Hegarty wrote:
>
>> On 16 Jul 2020, at 15:49, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
>> ...
>>
>> [1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.4/
>>
>> [2] http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.4/
>>
>> [3] http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.4/overview-summary.html
>>
> 1) I?d still like to see "an unnamed UnixDomainSocketAddress" used instead of "UnixDomainSocketAddress with an empty path? - since we have a nice definition of _unnamed_ already.
Right, I meant to change that. Will do.
> 2) I wonder if we can add the following definitions:
>
>    ?channel for an Internet protocol socket?  - channel::getProtocolFamily returns one of INET or INET6
>
>    ?channel for a Unix domain socket? - channel::getProtocolFamily returns UNIX

I have re-organised the package level description to clearly put the 
definitions first, before they are referred to and have incorporated 
references to getProtocolFamily there too. Take a look and see what you 
think.

I have added a new revision of the webrevs/specdiffs including these and 
Daniel's comments at:

[1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.5/

[2] http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.5/

[3] http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.5/overview-summary.html

Thanks,

Michael

> -Chris.	

From daniel.fuchs at oracle.com  Fri Jul 17 15:42:28 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 17 Jul 2020 16:42:28 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <148bba6c-8a41-8ea4-7915-3da01eeb4e6c@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <69e05ea7-2b04-e043-ea82-821371a6d5a1@oracle.com>
 <148bba6c-8a41-8ea4-7915-3da01eeb4e6c@oracle.com>
Message-ID: <01ed17ef-657b-dc3c-ebdd-6b4041a66161@oracle.com>

Hi Michael,

On 17/07/2020 11:57, Michael McMahon wrote:
> Hi Daniel,
>> Maybe a sub-section "About UNIX domain" - similar to "About IPv6",
>> in either one of these two sections?
>>
> 
> I'm not sure. The package level docs for java.net don't mention
> SocketAddress or InetSocketAddress either. Maybe it should have a paragraph
> like that but I feel it's out of scope for this work.
> 
> I notice that there is no equivalent explanation relating to 
> StandardProtocolFamily
> which is also only used in NIO. Maybe both of these could be addressed 
> in another doc update?

I'll let you be the judge for that - it was just a suggestion,
prompted by the fact that UnixDomainSocketAddress is listed
in the classes section below - which could give the wrong
impression that Socket & friends might support it.

>> http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.4/java.base/java/net/package-summary.html 
>>
>>
>> Similarly - maybe UnixDomainSocketAddress could have an @see
>> pointing to the SocketChannel and ServerSocketChannel?
>>
> 
> I agree that is a simple change, which would be useful.

And maybe that's enough.

>> In 
>> http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.4/java.base/java/nio/channels/ServerSocketChannel.html 
>>
>> two args bind method > How about rewording as:
> 
>  ???? * @throws? SecurityException
>  ???? *????????? If a security manager has been installed and its {@link
>  ???? *????????? SecurityManager#checkListen checkListen} method denies
>  ???? *????????? the operation for an <i>Internet protocol</i> socket 
> address,
>  ???? *????????? or for a <i>Unix domain</i> socket address if it denies
>  ???? *????????? {@link NetPermission}{@code("allowUnixDomainChannels")}.

That sounds right. Thanks. I like this wording much better.

best regards,

-- daniel

From chris.hegarty at oracle.com  Fri Jul 17 15:54:09 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 17 Jul 2020 16:54:09 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
Message-ID: <0CA21A3F-FA39-4878-9D0F-E611E1CD3041@oracle.com>

Michael,

> On 17 Jul 2020, at 15:57, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
> 
> ...
> 
> [3] http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.5/overview-summary.html
> 

The API looks very good to me.

A final minor picky comment:

* UnixDomainSocketAddress::equals should probably specify that
  two addresses are equal if their paths ( getPath() ) are equal.

-Chris.

From Alan.Bateman at oracle.com  Fri Jul 17 16:02:00 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 17 Jul 2020 17:02:00 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
Message-ID: <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>

On 17/07/2020 15:57, Michael McMahon wrote:
> :
>
> I have added a new revision of the webrevs/specdiffs including these 
> and Daniel's comments at:
>
> [1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.5/
How tied are you to adding getProtocolFamily to these APIs? It's 
technically an incompatible change to add abstract methods to these 
classes although the number of implementations outside of the JDK is 
probably tiny. I guess I'm mostly wondering if the method is actually 
useful. I could imagine a testing checking to see if a channel is 
unbound and then binding it to a socket address that is appropriate for 
the channel's socket but I'm less sure about other uses. Are you mostly 
thinking diagnostics, in which case it can be in the string representation.

-Alan

From michael.x.mcmahon at oracle.com  Fri Jul 17 16:36:52 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 17 Jul 2020 17:36:52 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <0CA21A3F-FA39-4878-9D0F-E611E1CD3041@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
 <0CA21A3F-FA39-4878-9D0F-E611E1CD3041@oracle.com>
Message-ID: <bae68609-a1b9-a92a-8fd3-e1c14f0fe7c5@oracle.com>


On 17/07/2020 16:54, Chris Hegarty wrote:
> Michael,
>
>> On 17 Jul 2020, at 15:57, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:
>>
>> ...
>>
>> [3] http://cr.openjdk.java.net/~michaelm/8245194/specdiff/specout.5/overview-summary.html
>>
> The API looks very good to me.
>
> A final minor picky comment:
>
> * UnixDomainSocketAddress::equals should probably specify that
>    two addresses are equal if their paths ( getPath() ) are equal.
>
> -Chris.

Do you think the @return is not sufficient?

 ???? * @return true if the path fields are equal

- Michael


From Alan.Bateman at oracle.com  Mon Jul 20 09:16:38 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 20 Jul 2020 10:16:38 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
 <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>
Message-ID: <137fa6e1-f777-63d7-dfc2-bf5c96a10c5a@oracle.com>

On 17/07/2020 17:02, Alan Bateman wrote:
> On 17/07/2020 15:57, Michael McMahon wrote:
>> :
>>
>> I have added a new revision of the webrevs/specdiffs including these 
>> and Daniel's comments at:
>>
>> [1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.5/
> How tied are you to adding getProtocolFamily to these APIs? It's 
> technically an incompatible change to add abstract methods to these 
> classes although the number of implementations outside of the JDK is 
> probably tiny. I guess I'm mostly wondering if the method is actually 
> useful. I could imagine a testing checking to see if a channel is 
> unbound and then binding it to a socket address that is appropriate 
> for the channel's socket but I'm less sure about other uses. Are you 
> mostly thinking diagnostics, in which case it can be in the string 
> representation.
One other comment on getProtocolFamily() is that if it is added then we 
should look at NetworkChannel as that's the interface that all channels 
to a socket implement.

A few other comments on the API webrev (v5):

NetPermission("allowUnixDomainChannels"). A coarse grain permission is 
fine but I'm not sure about the target name. It's not strictly tied to 
channels and the "allow" prefix is superfluous. You might want to 
consider something like "unixDomainSocket" and just specify that it is 
required in order to accept, bind, or connect a Unix domain socket.

UnixDomainSocketAddress. The javadoc for the factory methods should 
probably make it clear that the path can be empty. of(Path) might also 
need something to cover the corner case that the default file system is 
a custom file system (it will throw IAE for this case). The hashCode 
method specifies that the hash code is based on the path string where 
it's based on the Path object, might be simpler to just specify that it 
returns the hash code of the UnixDomainSocketAddress.

The javadoc updates to SocketChannel and ServerSocketChannel look okay 
to me. A few long length inconsistencies/formatting but these are just 
nits.

SelectorProvider. I don't think the list items need to repeat "Internet 
protocol" because it's already in the paragraph for the lists. Also just 
a minor point that there is no need for all the javadoc links to use 
qualified class names as SelectorProvider imports all these types.

The API additions to the jdk.net package look good too.

The first 3 paragraphs added to the java.nio.channels package 
description are okay.

I have a lot of comments on the additions to the java.nio.channel 
package description. Some of these paragraphs don't make sense here, 
e.g. paragraphs 4 and 5 candropped and replaced with an apiNote in 
DatagramChannel to say that channels to datagram-oriented sockets do not 
support Unix domain sockets. There is also a lot of text that is too 
specific to SocketChannel and ServerSocketChannel so I think we'll need 
to find a better place for this. I don't think there is any need to 
reference to the security manager as it is already covered by the API docs.

Are you proposing that the java.nio.channels.tmpdir property be standard 
or JDK specific? I think we need to know this before suggesting a name 
for this property.

Overall I think the API/docs are looking quite good, just not sure about 
getProtocolFamily and the additions to the package description will 
probably go through a few iterations.

-Alan.

From michael.x.mcmahon at oracle.com  Mon Jul 20 14:38:09 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 20 Jul 2020 15:38:09 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <137fa6e1-f777-63d7-dfc2-bf5c96a10c5a@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
 <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>
 <137fa6e1-f777-63d7-dfc2-bf5c96a10c5a@oracle.com>
Message-ID: <e94369b1-3f73-7f13-6843-cfbafbb50fa4@oracle.com>


On 20/07/2020 10:16, Alan Bateman wrote:
> On 17/07/2020 17:02, Alan Bateman wrote:
>> On 17/07/2020 15:57, Michael McMahon wrote:
>>> :
>>>
>>> I have added a new revision of the webrevs/specdiffs including these 
>>> and Daniel's comments at:
>>>
>>> [1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.5/
>> How tied are you to adding getProtocolFamily to these APIs? It's 
>> technically an incompatible change to add abstract methods to these 
>> classes although the number of implementations outside of the JDK is 
>> probably tiny. I guess I'm mostly wondering if the method is actually 
>> useful. I could imagine a testing checking to see if a channel is 
>> unbound and then binding it to a socket address that is appropriate 
>> for the channel's socket but I'm less sure about other uses. Are you 
>> mostly thinking diagnostics, in which case it can be in the string 
>> representation.
> One other comment on getProtocolFamily() is that if it is added then 
> we should look at NetworkChannel as that's the interface that all 
> channels to a socket implement.
>
Right. I'm questioning now whether it is worth it. I don't see any 
compelling use cases at this point and I hadn't considered other 
potential implementations and what any default implementations of the 
method should return. I found it didn't improve the spec in the way I 
expected either. So, I propose to drop it at this point.
> A few other comments on the API webrev (v5):
>
> NetPermission("allowUnixDomainChannels"). A coarse grain permission is 
> fine but I'm not sure about the target name. It's not strictly tied to 
> channels and the "allow" prefix is superfluous. You might want to 
> consider something like "unixDomainSocket" and just specify that it is 
> required in order to accept, bind, or connect a Unix domain socket.
>
ok "unixDomainSocket" seems fine.
> UnixDomainSocketAddress. The javadoc for the factory methods should 
> probably make it clear that the path can be empty. of(Path) might also 
> need something to cover the corner case that the default file system 
> is a custom file system (it will throw IAE for this case). The 
> hashCode method specifies that the hash code is based on the path 
> string where it's based on the Path object, might be simpler to just 
> specify that it returns the hash code of the UnixDomainSocketAddress.
>
Ok, except the static of(Path) method already specifies in the @throws 
that it throws IAE if the path comes from a filesystem other than the 
system default? Is that not sufficient?

> The javadoc updates to SocketChannel and ServerSocketChannel look okay 
> to me. A few long length inconsistencies/formatting but these are just 
> nits.
>
> SelectorProvider. I don't think the list items need to repeat 
> "Internet protocol" because it's already in the paragraph for the 
> lists. Also just a minor point that there is no need for all the 
> javadoc links to use qualified class names as SelectorProvider imports 
> all these types.
>
OK
> The API additions to the jdk.net package look good too.
>
> The first 3 paragraphs added to the java.nio.channels package 
> description are okay.
>
> I have a lot of comments on the additions to the java.nio.channel 
> package description. Some of these paragraphs don't make sense here, 
> e.g. paragraphs 4 and 5 candropped and replaced with an apiNote in 
> DatagramChannel to say that channels to datagram-oriented sockets do 
> not support Unix domain sockets. There is also a lot of text that is 
> too specific to SocketChannel and ServerSocketChannel so I think we'll 
> need to find a better place for this. I don't think there is any need 
> to reference to the security manager as it is already covered by the 
> API docs.
>
OK, I've made some of the updates above, but have not moved the 
paragraphs relating to SocketChannel/ServerSocketChannel, as I don't 
know where to move them to and I think
the details are important.


> Are you proposing that the java.nio.channels.tmpdir property be 
> standard or JDK specific? I think we need to know this before 
> suggesting a name for this property.
>
My suggestion would be Java SE as I think it will need to be quite visible.


> Overall I think the API/docs are looking quite good, just not sure 
> about getProtocolFamily and the additions to the package description 
> will probably go through a few iterations.
>
Okay, thanks.

- Michael


From brian.burkhalter at oracle.com  Mon Jul 20 21:41:59 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 20 Jul 2020 14:41:59 -0700
Subject: [16] 8249772: (ch) Improve sun/nio/ch/TestMaxCachedBufferSize.java
Message-ID: <215BB0E5-B309-4178-9838-3A4BAEBE57EA@oracle.com>

To resolve [1] the proposed change [2] would:

1. Compare the ending values of the direct buffer pool count and total capacity with their respective starting values instead of with zero.
2. Replace the use of Random with a SplittableRandom obtained from RandomFactory.
3. Increase the intra-loop verbosity from 2 to 10 prints per thread.

The change would also remove the test from the problem list so that if it fails again, then more information might be available to help with fixing [3].

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8249772
[2] http://cr.openjdk.java.net/~bpb/8249772/webrev.00/
[3] https://bugs.openjdk.java.net/browse/JDK-8212812

From michael.x.mcmahon at oracle.com  Tue Jul 21 11:58:40 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 21 Jul 2020 12:58:40 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <e94369b1-3f73-7f13-6843-cfbafbb50fa4@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
 <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>
 <137fa6e1-f777-63d7-dfc2-bf5c96a10c5a@oracle.com>
 <e94369b1-3f73-7f13-6843-cfbafbb50fa4@oracle.com>
Message-ID: <c5e97ac9-503e-1c3d-9ca5-ff8254c83906@oracle.com>

Alan

I have updated the API webrev [1], impl webrev [2] and specdiff [3]. A 
couple of things I reconsidered since my last reply:

- I have removed the paragraphs relating to SocketChannel and 
ServerSocketChannel behavior for Unix Domain from the package-info and 
added a small amount of related text to the @apiNote to both classes' 
bind methods

- I am thinking now the system property for overriding the temporary 
socket file directory should not be part of the Java SE spec. So, it 
does not now appear anywhere in the api doc. We will probably have to 
choose a different name for it and decide where it could be documented 
instead.

One thing I just noticed is that the NetPermission("unixDomainSocket") 
looks a little out of place compared to the other permission targets in 
that class as they all have a verb like "allow", or "get" prefixing the 
name. So, I wonder if it might be better as "allowUnixDomainSocket"?

Thanks,

Michael


[1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.6/

[2] http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.6/

[1] http://cr.openjdk.java.net/~michaelm/8245194/specdiff/webrev.6/

On 20/07/2020 15:38, Michael McMahon wrote:
>
> On 20/07/2020 10:16, Alan Bateman wrote:
>> On 17/07/2020 17:02, Alan Bateman wrote:
>>> On 17/07/2020 15:57, Michael McMahon wrote:
>>>> :
>>>>
>>>> I have added a new revision of the webrevs/specdiffs including 
>>>> these and Daniel's comments at:
>>>>
>>>> [1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.5/
>>> How tied are you to adding getProtocolFamily to these APIs? It's 
>>> technically an incompatible change to add abstract methods to these 
>>> classes although the number of implementations outside of the JDK is 
>>> probably tiny. I guess I'm mostly wondering if the method is 
>>> actually useful. I could imagine a testing checking to see if a 
>>> channel is unbound and then binding it to a socket address that is 
>>> appropriate for the channel's socket but I'm less sure about other 
>>> uses. Are you mostly thinking diagnostics, in which case it can be 
>>> in the string representation.
>> One other comment on getProtocolFamily() is that if it is added then 
>> we should look at NetworkChannel as that's the interface that all 
>> channels to a socket implement.
>>
> Right. I'm questioning now whether it is worth it. I don't see any 
> compelling use cases at this point and I hadn't considered other 
> potential implementations and what any default implementations of the 
> method should return. I found it didn't improve the spec in the way I 
> expected either. So, I propose to drop it at this point.
>> A few other comments on the API webrev (v5):
>>
>> NetPermission("allowUnixDomainChannels"). A coarse grain permission 
>> is fine but I'm not sure about the target name. It's not strictly 
>> tied to channels and the "allow" prefix is superfluous. You might 
>> want to consider something like "unixDomainSocket" and just specify 
>> that it is required in order to accept, bind, or connect a Unix 
>> domain socket.
>>
> ok "unixDomainSocket" seems fine.
>> UnixDomainSocketAddress. The javadoc for the factory methods should 
>> probably make it clear that the path can be empty. of(Path) might 
>> also need something to cover the corner case that the default file 
>> system is a custom file system (it will throw IAE for this case). The 
>> hashCode method specifies that the hash code is based on the path 
>> string where it's based on the Path object, might be simpler to just 
>> specify that it returns the hash code of the UnixDomainSocketAddress.
>>
> Ok, except the static of(Path) method already specifies in the @throws 
> that it throws IAE if the path comes from a filesystem other than the 
> system default? Is that not sufficient?
>
>> The javadoc updates to SocketChannel and ServerSocketChannel look 
>> okay to me. A few long length inconsistencies/formatting but these 
>> are just nits.
>>
>> SelectorProvider. I don't think the list items need to repeat 
>> "Internet protocol" because it's already in the paragraph for the 
>> lists. Also just a minor point that there is no need for all the 
>> javadoc links to use qualified class names as SelectorProvider 
>> imports all these types.
>>
> OK
>> The API additions to the jdk.net package look good too.
>>
>> The first 3 paragraphs added to the java.nio.channels package 
>> description are okay.
>>
>> I have a lot of comments on the additions to the java.nio.channel 
>> package description. Some of these paragraphs don't make sense here, 
>> e.g. paragraphs 4 and 5 candropped and replaced with an apiNote in 
>> DatagramChannel to say that channels to datagram-oriented sockets do 
>> not support Unix domain sockets. There is also a lot of text that is 
>> too specific to SocketChannel and ServerSocketChannel so I think 
>> we'll need to find a better place for this. I don't think there is 
>> any need to reference to the security manager as it is already 
>> covered by the API docs.
>>
> OK, I've made some of the updates above, but have not moved the 
> paragraphs relating to SocketChannel/ServerSocketChannel, as I don't 
> know where to move them to and I think
> the details are important.
>
>
>> Are you proposing that the java.nio.channels.tmpdir property be 
>> standard or JDK specific? I think we need to know this before 
>> suggesting a name for this property.
>>
> My suggestion would be Java SE as I think it will need to be quite 
> visible.
>
>
>> Overall I think the API/docs are looking quite good, just not sure 
>> about getProtocolFamily and the additions to the package description 
>> will probably go through a few iterations.
>>
> Okay, thanks.
>
> - Michael
>

From macanaoire at hotmail.com  Wed Jul 22 16:15:15 2020
From: macanaoire at hotmail.com (mark sheppard)
Date: Wed, 22 Jul 2020 16:15:15 +0000
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <c5e97ac9-503e-1c3d-9ca5-ff8254c83906@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
 <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>
 <137fa6e1-f777-63d7-dfc2-bf5c96a10c5a@oracle.com>
 <e94369b1-3f73-7f13-6843-cfbafbb50fa4@oracle.com>,
 <c5e97ac9-503e-1c3d-9ca5-ff8254c83906@oracle.com>
Message-ID: <DBBPR09MB3014DEA0DF24B6D2616D222DDF790@DBBPR09MB3014.eurprd09.prod.outlook.com>

Hi Michael,
  I see that you have removed the getProtocolFamily method so the following suggestion may be
a moot point.
  In any case, one possible alternative approach for providing access to the ProtocolFamily attribute of
a {Server}SocketChannel, might be via a (socket) option type for the  getOption method, e.g.
SO_PROTOCOL_FAMILY ?  This is analogous to the SO_TYPE at the native OS system socket api level.
Might be worth considering, as previously there was some suggested value in having access to such information.

regards
Mark

________________________________
From: nio-dev <nio-dev-retn at openjdk.java.net> on behalf of Michael McMahon <michael.x.mcmahon at oracle.com>
Sent: Tuesday 21 July 2020 11:58
To: Alan Bateman <Alan.Bateman at oracle.com>; nio-dev at openjdk.java.net <nio-dev at openjdk.java.net>
Subject: Re: RFR 8245194: Unix domain socket channel implementation

Alan

I have updated the API webrev [1], impl webrev [2] and specdiff [3]. A
couple of things I reconsidered since my last reply:

- I have removed the paragraphs relating to SocketChannel and
ServerSocketChannel behavior for Unix Domain from the package-info and
added a small amount of related text to the @apiNote to both classes'
bind methods

- I am thinking now the system property for overriding the temporary
socket file directory should not be part of the Java SE spec. So, it
does not now appear anywhere in the api doc. We will probably have to
choose a different name for it and decide where it could be documented
instead.

One thing I just noticed is that the NetPermission("unixDomainSocket")
looks a little out of place compared to the other permission targets in
that class as they all have a verb like "allow", or "get" prefixing the
name. So, I wonder if it might be better as "allowUnixDomainSocket"?

Thanks,

Michael


[1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.6/

[2] http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.6/

[1] http://cr.openjdk.java.net/~michaelm/8245194/specdiff/webrev.6/

On 20/07/2020 15:38, Michael McMahon wrote:
>
> On 20/07/2020 10:16, Alan Bateman wrote:
>> On 17/07/2020 17:02, Alan Bateman wrote:
>>> On 17/07/2020 15:57, Michael McMahon wrote:
>>>> :
>>>>
>>>> I have added a new revision of the webrevs/specdiffs including
>>>> these and Daniel's comments at:
>>>>
>>>> [1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.5/
>>> How tied are you to adding getProtocolFamily to these APIs? It's
>>> technically an incompatible change to add abstract methods to these
>>> classes although the number of implementations outside of the JDK is
>>> probably tiny. I guess I'm mostly wondering if the method is
>>> actually useful. I could imagine a testing checking to see if a
>>> channel is unbound and then binding it to a socket address that is
>>> appropriate for the channel's socket but I'm less sure about other
>>> uses. Are you mostly thinking diagnostics, in which case it can be
>>> in the string representation.
>> One other comment on getProtocolFamily() is that if it is added then
>> we should look at NetworkChannel as that's the interface that all
>> channels to a socket implement.
>>
> Right. I'm questioning now whether it is worth it. I don't see any
> compelling use cases at this point and I hadn't considered other
> potential implementations and what any default implementations of the
> method should return. I found it didn't improve the spec in the way I
> expected either. So, I propose to drop it at this point.
>> A few other comments on the API webrev (v5):
>>
>> NetPermission("allowUnixDomainChannels"). A coarse grain permission
>> is fine but I'm not sure about the target name. It's not strictly
>> tied to channels and the "allow" prefix is superfluous. You might
>> want to consider something like "unixDomainSocket" and just specify
>> that it is required in order to accept, bind, or connect a Unix
>> domain socket.
>>
> ok "unixDomainSocket" seems fine.
>> UnixDomainSocketAddress. The javadoc for the factory methods should
>> probably make it clear that the path can be empty. of(Path) might
>> also need something to cover the corner case that the default file
>> system is a custom file system (it will throw IAE for this case). The
>> hashCode method specifies that the hash code is based on the path
>> string where it's based on the Path object, might be simpler to just
>> specify that it returns the hash code of the UnixDomainSocketAddress.
>>
> Ok, except the static of(Path) method already specifies in the @throws
> that it throws IAE if the path comes from a filesystem other than the
> system default? Is that not sufficient?
>
>> The javadoc updates to SocketChannel and ServerSocketChannel look
>> okay to me. A few long length inconsistencies/formatting but these
>> are just nits.
>>
>> SelectorProvider. I don't think the list items need to repeat
>> "Internet protocol" because it's already in the paragraph for the
>> lists. Also just a minor point that there is no need for all the
>> javadoc links to use qualified class names as SelectorProvider
>> imports all these types.
>>
> OK
>> The API additions to the jdk.net package look good too.
>>
>> The first 3 paragraphs added to the java.nio.channels package
>> description are okay.
>>
>> I have a lot of comments on the additions to the java.nio.channel
>> package description. Some of these paragraphs don't make sense here,
>> e.g. paragraphs 4 and 5 candropped and replaced with an apiNote in
>> DatagramChannel to say that channels to datagram-oriented sockets do
>> not support Unix domain sockets. There is also a lot of text that is
>> too specific to SocketChannel and ServerSocketChannel so I think
>> we'll need to find a better place for this. I don't think there is
>> any need to reference to the security manager as it is already
>> covered by the API docs.
>>
> OK, I've made some of the updates above, but have not moved the
> paragraphs relating to SocketChannel/ServerSocketChannel, as I don't
> know where to move them to and I think
> the details are important.
>
>
>> Are you proposing that the java.nio.channels.tmpdir property be
>> standard or JDK specific? I think we need to know this before
>> suggesting a name for this property.
>>
> My suggestion would be Java SE as I think it will need to be quite
> visible.
>
>
>> Overall I think the API/docs are looking quite good, just not sure
>> about getProtocolFamily and the additions to the package description
>> will probably go through a few iterations.
>>
> Okay, thanks.
>
> - Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200722/e15a03c6/attachment.htm>

From michael.x.mcmahon at oracle.com  Thu Jul 23 08:57:48 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 23 Jul 2020 09:57:48 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <DBBPR09MB3014DEA0DF24B6D2616D222DDF790@DBBPR09MB3014.eurprd09.prod.outlook.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
 <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>
 <137fa6e1-f777-63d7-dfc2-bf5c96a10c5a@oracle.com>
 <e94369b1-3f73-7f13-6843-cfbafbb50fa4@oracle.com>
 <c5e97ac9-503e-1c3d-9ca5-ff8254c83906@oracle.com>
 <DBBPR09MB3014DEA0DF24B6D2616D222DDF790@DBBPR09MB3014.eurprd09.prod.outlook.com>
Message-ID: <e3bbd927-7e63-9183-3bb0-24eaae75f4cb@oracle.com>

Hi Mark


Thanks for reviewing the webrev.


I think that might be an option for providing the function at a JDK (non 
standard) level.

But, I don't currently see a strong enough justification for it.


Michael.


On 22/07/2020 17:15, mark sheppard wrote:
> Hi Michael,
> ? I see that you have removed the getProtocolFamily method so the 
> following suggestion may be
> a moot point.
> ? In any case, one possible alternative approach for providing access 
> to the ProtocolFamily attribute of
> a {Server}SocketChannel, might be via a (socket) option type for the 
> getOption method, e.g.
> SO_PROTOCOL_FAMILY ? ?This is analogous to the SO_TYPE at the native 
> OS system socket api level.
> Might be worth considering, as previously there was some suggested 
> value in having access to such information.
>
> regards
> Mark
>
> ------------------------------------------------------------------------
> *From:* nio-dev <nio-dev-retn at openjdk.java.net> on behalf of Michael 
> McMahon <michael.x.mcmahon at oracle.com>
> *Sent:* Tuesday 21 July 2020 11:58
> *To:* Alan Bateman <Alan.Bateman at oracle.com>; nio-dev at openjdk.java.net 
> <nio-dev at openjdk.java.net>
> *Subject:* Re: RFR 8245194: Unix domain socket channel implementation
> Alan
>
> I have updated the API webrev [1], impl webrev [2] and specdiff [3]. A
> couple of things I reconsidered since my last reply:
>
> - I have removed the paragraphs relating to SocketChannel and
> ServerSocketChannel behavior for Unix Domain from the package-info and
> added a small amount of related text to the @apiNote to both classes'
> bind methods
>
> - I am thinking now the system property for overriding the temporary
> socket file directory should not be part of the Java SE spec. So, it
> does not now appear anywhere in the api doc. We will probably have to
> choose a different name for it and decide where it could be documented
> instead.
>
> One thing I just noticed is that the NetPermission("unixDomainSocket")
> looks a little out of place compared to the other permission targets in
> that class as they all have a verb like "allow", or "get" prefixing the
> name. So, I wonder if it might be better as "allowUnixDomainSocket"?
>
> Thanks,
>
> Michael
>
>
> [1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.6/
>
> [2] http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.6/
>
> [1] http://cr.openjdk.java.net/~michaelm/8245194/specdiff/webrev.6/
>
> On 20/07/2020 15:38, Michael McMahon wrote:
> >
> > On 20/07/2020 10:16, Alan Bateman wrote:
> >> On 17/07/2020 17:02, Alan Bateman wrote:
> >>> On 17/07/2020 15:57, Michael McMahon wrote:
> >>>> :
> >>>>
> >>>> I have added a new revision of the webrevs/specdiffs including
> >>>> these and Daniel's comments at:
> >>>>
> >>>> [1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.5/
> >>> How tied are you to adding getProtocolFamily to these APIs? It's
> >>> technically an incompatible change to add abstract methods to these
> >>> classes although the number of implementations outside of the JDK is
> >>> probably tiny. I guess I'm mostly wondering if the method is
> >>> actually useful. I could imagine a testing checking to see if a
> >>> channel is unbound and then binding it to a socket address that is
> >>> appropriate for the channel's socket but I'm less sure about other
> >>> uses. Are you mostly thinking diagnostics, in which case it can be
> >>> in the string representation.
> >> One other comment on getProtocolFamily() is that if it is added then
> >> we should look at NetworkChannel as that's the interface that all
> >> channels to a socket implement.
> >>
> > Right. I'm questioning now whether it is worth it. I don't see any
> > compelling use cases at this point and I hadn't considered other
> > potential implementations and what any default implementations of the
> > method should return. I found it didn't improve the spec in the way I
> > expected either. So, I propose to drop it at this point.
> >> A few other comments on the API webrev (v5):
> >>
> >> NetPermission("allowUnixDomainChannels"). A coarse grain permission
> >> is fine but I'm not sure about the target name. It's not strictly
> >> tied to channels and the "allow" prefix is superfluous. You might
> >> want to consider something like "unixDomainSocket" and just specify
> >> that it is required in order to accept, bind, or connect a Unix
> >> domain socket.
> >>
> > ok "unixDomainSocket" seems fine.
> >> UnixDomainSocketAddress. The javadoc for the factory methods should
> >> probably make it clear that the path can be empty. of(Path) might
> >> also need something to cover the corner case that the default file
> >> system is a custom file system (it will throw IAE for this case). The
> >> hashCode method specifies that the hash code is based on the path
> >> string where it's based on the Path object, might be simpler to just
> >> specify that it returns the hash code of the UnixDomainSocketAddress.
> >>
> > Ok, except the static of(Path) method already specifies in the @throws
> > that it throws IAE if the path comes from a filesystem other than the
> > system default? Is that not sufficient?
> >
> >> The javadoc updates to SocketChannel and ServerSocketChannel look
> >> okay to me. A few long length inconsistencies/formatting but these
> >> are just nits.
> >>
> >> SelectorProvider. I don't think the list items need to repeat
> >> "Internet protocol" because it's already in the paragraph for the
> >> lists. Also just a minor point that there is no need for all the
> >> javadoc links to use qualified class names as SelectorProvider
> >> imports all these types.
> >>
> > OK
> >> The API additions to the jdk.net package look good too.
> >>
> >> The first 3 paragraphs added to the java.nio.channels package
> >> description are okay.
> >>
> >> I have a lot of comments on the additions to the java.nio.channel
> >> package description. Some of these paragraphs don't make sense here,
> >> e.g. paragraphs 4 and 5 candropped and replaced with an apiNote in
> >> DatagramChannel to say that channels to datagram-oriented sockets do
> >> not support Unix domain sockets. There is also a lot of text that is
> >> too specific to SocketChannel and ServerSocketChannel so I think
> >> we'll need to find a better place for this. I don't think there is
> >> any need to reference to the security manager as it is already
> >> covered by the API docs.
> >>
> > OK, I've made some of the updates above, but have not moved the
> > paragraphs relating to SocketChannel/ServerSocketChannel, as I don't
> > know where to move them to and I think
> > the details are important.
> >
> >
> >> Are you proposing that the java.nio.channels.tmpdir property be
> >> standard or JDK specific? I think we need to know this before
> >> suggesting a name for this property.
> >>
> > My suggestion would be Java SE as I think it will need to be quite
> > visible.
> >
> >
> >> Overall I think the API/docs are looking quite good, just not sure
> >> about getProtocolFamily and the additions to the package description
> >> will probably go through a few iterations.
> >>
> > Okay, thanks.
> >
> > - Michael
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200723/6d641a59/attachment-0001.htm>

From Alan.Bateman at oracle.com  Sun Jul 26 06:44:43 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 26 Jul 2020 07:44:43 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <e3bbd927-7e63-9183-3bb0-24eaae75f4cb@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
 <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>
 <137fa6e1-f777-63d7-dfc2-bf5c96a10c5a@oracle.com>
 <e94369b1-3f73-7f13-6843-cfbafbb50fa4@oracle.com>
 <c5e97ac9-503e-1c3d-9ca5-ff8254c83906@oracle.com>
 <DBBPR09MB3014DEA0DF24B6D2616D222DDF790@DBBPR09MB3014.eurprd09.prod.outlook.com>
 <e3bbd927-7e63-9183-3bb0-24eaae75f4cb@oracle.com>
Message-ID: <3a3e46c2-2c20-1e01-9840-d027518d29e4@oracle.com>

On 23/07/2020 09:57, Michael McMahon wrote:
>
> Hi Mark
>
>
> Thanks for reviewing the webrev.
>
>
> I think that might be an option for providing the function at a JDK 
> (non standard) level.
>
> But, I don't currently see a strong enough justification for it.
>
I think Mark's suggestion of a socket option would be a feasible 
alternative to adding a method to NetworkChannel. However, I agree, 
there doesn't seem to be a strong need for this at this time and it's 
better to keep it out of this JEP.

-Alan

From Alan.Bateman at oracle.com  Sun Jul 26 06:56:32 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 26 Jul 2020 07:56:32 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <c5e97ac9-503e-1c3d-9ca5-ff8254c83906@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
 <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>
 <137fa6e1-f777-63d7-dfc2-bf5c96a10c5a@oracle.com>
 <e94369b1-3f73-7f13-6843-cfbafbb50fa4@oracle.com>
 <c5e97ac9-503e-1c3d-9ca5-ff8254c83906@oracle.com>
Message-ID: <ab006448-6171-4feb-0ad9-a2a798eee854@oracle.com>

On 21/07/2020 12:58, Michael McMahon wrote:
> :
>
> One thing I just noticed is that the NetPermission("unixDomainSocket") 
> looks a little out of place compared to the other permission targets 
> in that class as they all have a verb like "allow", or "get" prefixing 
> the name. So, I wonder if it might be better as "allowUnixDomainSocket"?
I don't have a strong preference on the permission target name. My 
original concern was that it used "Channel" rather than "Socket" and 
you've addressed that.? The only "allowXXX" target name that I could 
find is "allowHttpTrace" in NetPermission. RuntimePermission has a long 
list of targets with several named "accessXXXX" and maybe that 
convention could work here as "access" applies to several operations.

-Alan

From Alan.Bateman at oracle.com  Sun Jul 26 07:53:05 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 26 Jul 2020 08:53:05 +0100
Subject: [16] 8249772: (ch) Improve sun/nio/ch/TestMaxCachedBufferSize.java
In-Reply-To: <215BB0E5-B309-4178-9838-3A4BAEBE57EA@oracle.com>
References: <215BB0E5-B309-4178-9838-3A4BAEBE57EA@oracle.com>
Message-ID: <1d127647-1611-18a6-a3f6-3d1ae5aca250@oracle.com>

On 20/07/2020 22:41, Brian Burkhalter wrote:
> To resolve [1] the proposed change [2] would:
>
> 1. Compare the ending values of the direct buffer pool count and total capacity with their respective starting values instead of with zero.
> 2. Replace the use of Random with a SplittableRandom obtained from RandomFactory.
> 3. Increase the intra-loop verbosity from 2 to 10 prints per thread.
>
I think this looks okay, just make sure it runs many times on all 
platforms before pushing to ensure that it is stable.

In passing, the imports on this test are a bit messy and should be 
re-ordered. Also would be nicer to avoid the line break at L80-81. No 
need for another webrev if you do these cleanups.

-Alan

From Alan.Bateman at oracle.com  Mon Jul 27 07:24:00 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 Jul 2020 08:24:00 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <c5e97ac9-503e-1c3d-9ca5-ff8254c83906@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
 <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>
 <137fa6e1-f777-63d7-dfc2-bf5c96a10c5a@oracle.com>
 <e94369b1-3f73-7f13-6843-cfbafbb50fa4@oracle.com>
 <c5e97ac9-503e-1c3d-9ca5-ff8254c83906@oracle.com>
Message-ID: <bb392778-7331-3163-30d7-31d45cd612f2@oracle.com>

On 21/07/2020 12:58, Michael McMahon wrote:
> Alan
>
> I have updated the API webrev [1]
>
> [1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.6/
I did another pass over the latest webrev for the API changes (webrev.6) 
and overall it is looking very good.

One thing that I think needs another iteration is the package 
description as the text is a bit of out place. If we are adding text 
about network channels then it would be better to put it in section 
further up that has the table of for selectable channels. This would 
keep the flow and avoids having text for selectable channels in two 
places. The reference to the legacy java.net.preferIPv4Stack system 
property also looks out of place. Maybe we can just put an @see in the 
static open methods instead? There are also a bunch of imports into 
package-info that I assume are left over from previous iterations.

A minor nit in the wording is that SC.connect throws 
UnresolvedAddressException. I think it would be more correct to say 
"that is not fully resolved".

-Alan

From matthias.baesken at sap.com  Wed Jul 29 10:10:00 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 29 Jul 2020 10:10:00 +0000
Subject: RFR: [XS] 8250770 : Net.java translateToSocketException does not
 handle IOException
Message-ID: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>

Hello, it seems that  recent changes  to jdk/jdk caused that we see on some Windows machines  in Net.java  translateToSocketException ,  that  an IOException  occurs :

Caused by: java.io.IOException: Network interface not configured for IPv4" ; the IOException could (should?) be translated to a SocketException in Net.java

And this is unfortunately not (yet)  translated .
My small change adds  the "translation"  of the IOException to  translateToSocketException  .

The issue was caused by a :

Caused by: java.io.IOException: Network interface not configured for IPv4
at java.base/sun.nio.ch.DatagramChannelImpl.setOption(DatagramChannelImpl.java:376)
at java.base/sun.nio.ch.DatagramSocketAdaptor.setOption(DatagramSocketAdaptor.java:418)
at java.base/sun.nio.ch.DatagramSocketAdaptor.setNetworkInterface(DatagramSocketAdaptor.java:600)


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8250770

http://cr.openjdk.java.net/~mbaesken/webrevs/8250770.0/

Thanks, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200729/bcefd349/attachment.htm>

From Alan.Bateman at oracle.com  Wed Jul 29 10:23:35 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Jul 2020 11:23:35 +0100
Subject: RFR: [XS] 8250770 : Net.java translateToSocketException does not
 handle IOException
In-Reply-To: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>
References: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>
Message-ID: <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>

On 29/07/2020 11:10, Baesken, Matthias wrote:
>
> Hello, it seems that ?recent changes ?to jdk/jdk caused that we see on 
> some Windows machines ?in Net.java? translateToSocketException ,? that 
> an IOException? occurs :**
>
> Caused by: java.io.IOException: Network interface not configured for 
> IPv4" ; the IOException could (should?) be translated to a 
> SocketException in Net.java
>
> And this is unfortunately not (yet) ?translated .
>
> My small change adds the ?translation?? of the IOException to 
> translateToSocketException? .
>
> The issue was caused by a :
>
> Caused by: java.io.IOException: Network interface not configured for IPv4
> at 
> java.base/sun.nio.ch.DatagramChannelImpl.setOption(DatagramChannelImpl.java:376)
> at 
> java.base/sun.nio.ch.DatagramSocketAdaptor.setOption(DatagramSocketAdaptor.java:418)
> at 
> java.base/sun.nio.ch.DatagramSocketAdaptor.setNetworkInterface(DatagramSocketAdaptor.java:600)
>
> Bug/webrev :
>
> https://bugs.openjdk.java.net/browse/JDK-8250770
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8250770.0/
>
>
This seems to be a long standing issue in the socket adaptors. Legacy 
DatagramSocket/MulticastSocket delegate to a socket adaptor since JDK 15 
so I assume this is why you only see this now. Changing 
translateToSocketException seems okay but "IO error" is going to be 
confusing. Can you use x.getMessage() as the message instead?

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200729/9248c7a1/attachment.htm>

From daniel.fuchs at oracle.com  Wed Jul 29 10:29:31 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 Jul 2020 11:29:31 +0100
Subject: RFR: [XS] 8250770 : Net.java translateToSocketException does not
 handle IOException
In-Reply-To: <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>
References: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>
Message-ID: <705d6592-ee55-759b-14ba-98cda818db54@oracle.com>

Hi Matthias,

On 29/07/2020 11:23, Alan Bateman wrote:
>> Bug/webrev :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8250770
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8250770.0/
>>
>>
> This seems to be a long standing issue in the socket adaptors. Legacy 
> DatagramSocket/MulticastSocket delegate to a socket adaptor since JDK 15 
> so I assume this is why you only see this now. Changing 
> translateToSocketException seems okay but "IO error" is going to be 
> confusing. Can you use x.getMessage() as the message instead?


I agree with Alan that at least the message of the original
exception should be kept. I wonder if we should keep the
original IOException as the cause as well.

Something like:

    nx = new SocketException(x.getMessage());
    nx.initCause(x);

best regards,

-- daniel

From Alan.Bateman at oracle.com  Wed Jul 29 10:35:53 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Jul 2020 11:35:53 +0100
Subject: RFR: [XS] 8250770 : Net.java translateToSocketException does not
 handle IOException
In-Reply-To: <705d6592-ee55-759b-14ba-98cda818db54@oracle.com>
References: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>
 <705d6592-ee55-759b-14ba-98cda818db54@oracle.com>
Message-ID: <625e2afb-2b2a-0f87-ebc3-12c174df2375@oracle.com>

On 29/07/2020 11:29, Daniel Fuchs wrote:
>
>
> I agree with Alan that at least the message of the original
> exception should be kept. I wonder if we should keep the
> original IOException as the cause as well.
>
> Something like:
>
> ?? nx = new SocketException(x.getMessage());
> ?? nx.initCause(x);
The translation already sets the cause so we are okay on that point.

-Alan

From daniel.fuchs at oracle.com  Wed Jul 29 10:37:49 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 Jul 2020 11:37:49 +0100
Subject: RFR: [XS] 8250770 : Net.java translateToSocketException does not
 handle IOException
In-Reply-To: <625e2afb-2b2a-0f87-ebc3-12c174df2375@oracle.com>
References: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>
 <705d6592-ee55-759b-14ba-98cda818db54@oracle.com>
 <625e2afb-2b2a-0f87-ebc3-12c174df2375@oracle.com>
Message-ID: <32f575f4-1a0c-5291-a164-6cc9a5726f3b@oracle.com>

On 29/07/2020 11:35, Alan Bateman wrote:
> The translation already sets the cause so we are okay on that point.
Doh. I missed that. And it's only two lines below.

Thanks Alan!

-- daniel



From matthias.baesken at sap.com  Wed Jul 29 10:39:40 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 29 Jul 2020 10:39:40 +0000
Subject: RFR: [XS] 8250770 : Net.java translateToSocketException does not
 handle IOException
In-Reply-To: <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>
References: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>
Message-ID: <AM0PR02MB5412D48FAA3B9D2A71522BC093700@AM0PR02MB5412.eurprd02.prod.outlook.com>

Hi Alan , thanks for your input .  What about :

nx = new SocketException("IO error:" + x.getMessage());

?

>This seems to be a long standing issue in the socket adaptors. Legacy DatagramSocket/MulticastSocket delegate to a socket adaptor since JDK 15 so I assume this is why you only see this now.
> Changing translateToSocketException seems okay but "IO error" is going to be confusing. Can you >use x.getMessage() as the message instead?


Best regards, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200729/3333a7be/attachment.htm>

From Alan.Bateman at oracle.com  Wed Jul 29 10:46:24 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Jul 2020 11:46:24 +0100
Subject: RFR: [XS] 8250770 : Net.java translateToSocketException does not
 handle IOException
In-Reply-To: <AM0PR02MB5412D48FAA3B9D2A71522BC093700@AM0PR02MB5412.eurprd02.prod.outlook.com>
References: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>
 <AM0PR02MB5412D48FAA3B9D2A71522BC093700@AM0PR02MB5412.eurprd02.prod.outlook.com>
Message-ID: <dcde119e-8091-bbd8-ea21-b676683c5753@oracle.com>

On 29/07/2020 11:39, Baesken, Matthias wrote:
>
> Hi Alan , thanks for your input .? What about :
>
> nx = new SocketException("IO error:" + x.getMessage());
>
>
We use "I/O rather than "IO" but I don't think the prefix is useful (as 
the IOException should have a good message).

We need to decide if this should be a P2 and target 15 (as in 
jdk/jdk15). Do you know if conformance test was passing on this system 
with JDK 14? The JEP 373 changes to switch MulticastSocket to use a 
socket adaptor went into JDK 15 so I assume it must be failing there.

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200729/3e6c5ab4/attachment.htm>

From matthias.baesken at sap.com  Wed Jul 29 10:59:39 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 29 Jul 2020 10:59:39 +0000
Subject: RFR: [XS] 8250770 : Net.java translateToSocketException does not
 handle IOException
In-Reply-To: <dcde119e-8091-bbd8-ea21-b676683c5753@oracle.com>
References: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>
 <AM0PR02MB5412D48FAA3B9D2A71522BC093700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dcde119e-8091-bbd8-ea21-b676683c5753@oracle.com>
Message-ID: <AM0PR02MB5412C7AD9FF7E3077905D8AA93700@AM0PR02MB5412.eurprd02.prod.outlook.com>


>We use "I/O rather than "IO" but I don't think the prefix is useful (as the IOException should have a good message).

>We need to decide if this should be a P2 and target 15 (as in jdk/jdk15). Do you know if conformance test was passing on this system with JDK 14? The JEP 373 changes to switch MulticastSocket to use a socket adaptor went into JDK 15 so I assume it must be failing there.


Hi Alan,  new webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8250770.1/

I did not notice the issue with JDK14 .
Best regards, Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200729/4f9110da/attachment-0001.htm>

From Alan.Bateman at oracle.com  Wed Jul 29 11:04:41 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Jul 2020 12:04:41 +0100
Subject: RFR: [XS] 8250770 : Net.java translateToSocketException does not
 handle IOException
In-Reply-To: <AM0PR02MB5412C7AD9FF7E3077905D8AA93700@AM0PR02MB5412.eurprd02.prod.outlook.com>
References: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>
 <AM0PR02MB5412D48FAA3B9D2A71522BC093700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dcde119e-8091-bbd8-ea21-b676683c5753@oracle.com>
 <AM0PR02MB5412C7AD9FF7E3077905D8AA93700@AM0PR02MB5412.eurprd02.prod.outlook.com>
Message-ID: <09a58d22-5856-e2e7-f95a-bbbf51f6339b@oracle.com>

On 29/07/2020 11:59, Baesken, Matthias wrote:
>
>
> Hi Alan,? new webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8250770.1/
>
> I did not notice the issue with JDK14 .
>
Can you try JDK 15? I suspect we have to make this a P2 and get it 
approved for jdk/jdk15.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200729/b864f5c5/attachment.htm>

From matthias.baesken at sap.com  Wed Jul 29 11:14:17 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 29 Jul 2020 11:14:17 +0000
Subject: RFR: [XS] 8250770 : Net.java translateToSocketException does not
 handle IOException
In-Reply-To: <09a58d22-5856-e2e7-f95a-bbbf51f6339b@oracle.com>
References: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>
 <AM0PR02MB5412D48FAA3B9D2A71522BC093700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dcde119e-8091-bbd8-ea21-b676683c5753@oracle.com>
 <AM0PR02MB5412C7AD9FF7E3077905D8AA93700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <09a58d22-5856-e2e7-f95a-bbbf51f6339b@oracle.com>
Message-ID: <AM0PR02MB5412C78686A5F682881045F393700@AM0PR02MB5412.eurprd02.prod.outlook.com>

Hi Alan,  I found a few  JDK15 jck errors  related to this one in our test-DB . So yes, it  is a JDK15 issue as well .

Best regards, Matthias

From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: Mittwoch, 29. Juli 2020 13:05
To: Baesken, Matthias <matthias.baesken at sap.com>; nio-dev at openjdk.java.net
Cc: Zeller, Arno <arno.zeller at sap.com>
Subject: Re: RFR: [XS] 8250770 : Net.java translateToSocketException does not handle IOException

On 29/07/2020 11:59, Baesken, Matthias wrote:



Hi Alan,  new webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8250770.1/

I did not notice the issue with JDK14 .
Can you try JDK 15? I suspect we have to make this a P2 and get it approved for jdk/jdk15.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200729/3417beeb/attachment.htm>

From Alan.Bateman at oracle.com  Wed Jul 29 12:54:44 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Jul 2020 13:54:44 +0100
Subject: RFR: [XS] 8250770 : Net.java translateToSocketException does not
 handle IOException
In-Reply-To: <AM0PR02MB5412C78686A5F682881045F393700@AM0PR02MB5412.eurprd02.prod.outlook.com>
References: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>
 <AM0PR02MB5412D48FAA3B9D2A71522BC093700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dcde119e-8091-bbd8-ea21-b676683c5753@oracle.com>
 <AM0PR02MB5412C7AD9FF7E3077905D8AA93700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <09a58d22-5856-e2e7-f95a-bbbf51f6339b@oracle.com>
 <AM0PR02MB5412C78686A5F682881045F393700@AM0PR02MB5412.eurprd02.prod.outlook.com>
Message-ID: <0afa1f38-ff59-d0c4-b773-40f75c62413e@oracle.com>

On 29/07/2020 12:14, Baesken, Matthias wrote:
>
> Hi Alan,? I found a few JDK15 jck errors ?related to this one in our 
> test-DB . So yes, it ?is a JDK15 issue as well .
>
>
Can you add jdk15-fix-request to the issue with a comment requesting 
approval for jdk/jdk15? I can approve and that will get this regression 
out of the way.

Also is there anything special about these test runs or Windows 
machines? The issue hints that there are network interfaces configured 
with IPv6 but the tests are being run with preferIPv4Stack=true.

-Alan

[1] http://openjdk.java.net/jeps/3#Fix-Request-Process
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200729/89e2e002/attachment.htm>

From arno.zeller at sap.com  Wed Jul 29 13:56:46 2020
From: arno.zeller at sap.com (Zeller, Arno)
Date: Wed, 29 Jul 2020 13:56:46 +0000
Subject: RFR: [XS] 8250770 : Net.java translateToSocketException does not
 handle IOException
In-Reply-To: <0afa1f38-ff59-d0c4-b773-40f75c62413e@oracle.com>
References: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>
 <AM0PR02MB5412D48FAA3B9D2A71522BC093700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dcde119e-8091-bbd8-ea21-b676683c5753@oracle.com>
 <AM0PR02MB5412C7AD9FF7E3077905D8AA93700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <09a58d22-5856-e2e7-f95a-bbbf51f6339b@oracle.com>
 <AM0PR02MB5412C78686A5F682881045F393700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <0afa1f38-ff59-d0c4-b773-40f75c62413e@oracle.com>
Message-ID: <VI1PR02MB5294B274A508844CA12107F2E3700@VI1PR02MB5294.eurprd02.prod.outlook.com>

Hi Alan,

you are absolutely right - the tests are run with preferIPv4Stack=true and on the test machine is one network interface (an isatap network adapter) that does only have an IPv6 address.

Best regards,
Arno

>From: Alan Bateman <Alan.Bateman at oracle.com> 
>Subject: Re: RFR: [XS] 8250770 : Net.java translateToSocketException does not handle IOException
>
>On 29/07/2020 12:14, Baesken, Matthias wrote:
>
>>              Hi Alan,? I found a few? JDK15 jck errors ?related to this one in our test-DB . So yes, it ?is a JDK15 issue as well .
>
>Can you add jdk15-fix-request to the issue with a comment requesting approval for jdk/jdk15? I can approve and that will get this regression out of the way.
>
>Also is there anything special about these test runs or Windows machines? The issue hints that there are network interfaces configured with IPv6 but the tests are being run with preferIPv4Stack=true.
>
>-Alan
>
>[1] http://openjdk.java.net/jeps/3#Fix-Request-Process

From daniel.fuchs at oracle.com  Wed Jul 29 14:38:26 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 Jul 2020 15:38:26 +0100
Subject: RFR: [XS] 8250770 : Net.java translateToSocketException does not
 handle IOException
In-Reply-To: <VI1PR02MB5294B274A508844CA12107F2E3700@VI1PR02MB5294.eurprd02.prod.outlook.com>
References: <AM0PR02MB54122D152E5B0F7A84FF7F0193700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dd152912-75f5-19bb-b9a2-ae3c9df64988@oracle.com>
 <AM0PR02MB5412D48FAA3B9D2A71522BC093700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <dcde119e-8091-bbd8-ea21-b676683c5753@oracle.com>
 <AM0PR02MB5412C7AD9FF7E3077905D8AA93700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <09a58d22-5856-e2e7-f95a-bbbf51f6339b@oracle.com>
 <AM0PR02MB5412C78686A5F682881045F393700@AM0PR02MB5412.eurprd02.prod.outlook.com>
 <0afa1f38-ff59-d0c4-b773-40f75c62413e@oracle.com>
 <VI1PR02MB5294B274A508844CA12107F2E3700@VI1PR02MB5294.eurprd02.prod.outlook.com>
Message-ID: <1abe8e45-d0ab-8e3b-9a7d-be06245b2adb@oracle.com>

Thanks Arno.

I had a look at how NetworkInterface behaves in the presence
of preferIPv4Stack=true - and I believe that the fix proposed
by Matthias will make the test pass.

Please let us know if that's not the case.

+1 for Matthias! :-)

best regards,

-- daniel

On 29/07/2020 14:56, Zeller, Arno wrote:
> Hi Alan,
> 
> you are absolutely right - the tests are run with preferIPv4Stack=true and on the test machine is one network interface (an isatap network adapter) that does only have an IPv6 address.
> 
> Best regards,
> Arno
> 
>> From: Alan Bateman <Alan.Bateman at oracle.com>
>> Subject: Re: RFR: [XS] 8250770 : Net.java translateToSocketException does not handle IOException
>>
>> On 29/07/2020 12:14, Baesken, Matthias wrote:
>>
>>>               Hi Alan,? I found a few? JDK15 jck errors ?related to this one in our test-DB . So yes, it ?is a JDK15 issue as well .
>>
>> Can you add jdk15-fix-request to the issue with a comment requesting approval for jdk/jdk15? I can approve and that will get this regression out of the way.
>>
>> Also is there anything special about these test runs or Windows machines? The issue hints that there are network interfaces configured with IPv6 but the tests are being run with preferIPv4Stack=true.
>>
>> -Alan
>>
>> [1] http://openjdk.java.net/jeps/3#Fix-Request-Process


From michael.x.mcmahon at oracle.com  Wed Jul 29 17:11:37 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 29 Jul 2020 18:11:37 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <bb392778-7331-3163-30d7-31d45cd612f2@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
 <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>
 <137fa6e1-f777-63d7-dfc2-bf5c96a10c5a@oracle.com>
 <e94369b1-3f73-7f13-6843-cfbafbb50fa4@oracle.com>
 <c5e97ac9-503e-1c3d-9ca5-ff8254c83906@oracle.com>
 <bb392778-7331-3163-30d7-31d45cd612f2@oracle.com>
Message-ID: <b722afb6-7690-fb8c-2aa2-ee930cfbbb35@oracle.com>

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

Thanks,

Michael.

On 27/07/2020 08:24, Alan Bateman wrote:
> On 21/07/2020 12:58, Michael McMahon wrote:
>> Alan
>>
>> I have updated the API webrev [1]
>>
>> [1] http://cr.openjdk.java.net/~michaelm/8245194/api.webrev/webrev.6/
> I did another pass over the latest webrev for the API changes 
> (webrev.6) and overall it is looking very good.
>
> One thing that I think needs another iteration is the package 
> description as the text is a bit of out place. If we are adding text 
> about network channels then it would be better to put it in section 
> further up that has the table of for selectable channels. This would 
> keep the flow and avoids having text for selectable channels in two 
> places. The reference to the legacy java.net.preferIPv4Stack system 
> property also looks out of place. Maybe we can just put an @see in the 
> static open methods instead? There are also a bunch of imports into 
> package-info that I assume are left over from previous iterations.
>
> A minor nit in the wording is that SC.connect throws 
> UnresolvedAddressException. I think it would be more correct to say 
> "that is not fully resolved".
>
> -Alan

From Alan.Bateman at oracle.com  Fri Jul 31 07:59:36 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 31 Jul 2020 08:59:36 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <b722afb6-7690-fb8c-2aa2-ee930cfbbb35@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
 <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>
 <137fa6e1-f777-63d7-dfc2-bf5c96a10c5a@oracle.com>
 <e94369b1-3f73-7f13-6843-cfbafbb50fa4@oracle.com>
 <c5e97ac9-503e-1c3d-9ca5-ff8254c83906@oracle.com>
 <bb392778-7331-3163-30d7-31d45cd612f2@oracle.com>
 <b722afb6-7690-fb8c-2aa2-ee930cfbbb35@oracle.com>
Message-ID: <13914e0e-7060-3695-59f9-ad25052dffc7@oracle.com>

On 29/07/2020 18:11, Michael McMahon 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/
Thanks. I see the updated package description, the new @see in the 
static open methods, and the minor adjustment to the text for 
UnresolvedAddressException.

So thumbs up from me on the API/javadoc.

-Alan.

From chris.hegarty at oracle.com  Fri Jul 31 12:30:01 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 31 Jul 2020 13:30:01 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <b722afb6-7690-fb8c-2aa2-ee930cfbbb35@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
 <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>
 <137fa6e1-f777-63d7-dfc2-bf5c96a10c5a@oracle.com>
 <e94369b1-3f73-7f13-6843-cfbafbb50fa4@oracle.com>
 <c5e97ac9-503e-1c3d-9ca5-ff8254c83906@oracle.com>
 <bb392778-7331-3163-30d7-31d45cd612f2@oracle.com>
 <b722afb6-7690-fb8c-2aa2-ee930cfbbb35@oracle.com>
Message-ID: <B55D9B6C-9E26-422E-9766-2181A14A22F2@oracle.com>

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.

-Chris.

From michael.x.mcmahon at oracle.com  Fri Jul 31 13:45:37 2020
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 31 Jul 2020 14:45:37 +0100
Subject: RFR 8245194: Unix domain socket channel implementation
In-Reply-To: <B55D9B6C-9E26-422E-9766-2181A14A22F2@oracle.com>
References: <54c06fa3-dfbf-682d-1abf-5e62e743ecd6@oracle.com>
 <E31CBCD7-FBD4-4BBE-9AC9-0C84E44D9593@oracle.com>
 <1420e1d2-bb8e-e593-d208-9b1d18b75823@oracle.com>
 <02AD9B6F-F8E6-4224-847D-13995055ED71@oracle.com>
 <9913d157-e04f-53ab-38a9-cef142aec435@oracle.com>
 <343E178A-D7C1-49C8-B547-5C06471CAB6C@oracle.com>
 <0099cc22-fc7d-a211-e282-80e96f7bbc3b@oracle.com>
 <FDA186D0-47CA-4A42-BC03-C67203AD0A00@oracle.com>
 <18cf1157-5ce4-0120-9e44-aa99e261db69@oracle.com>
 <91549f2b-ab1e-fd92-ed4e-261955667463@oracle.com>
 <137fa6e1-f777-63d7-dfc2-bf5c96a10c5a@oracle.com>
 <e94369b1-3f73-7f13-6843-cfbafbb50fa4@oracle.com>
 <c5e97ac9-503e-1c3d-9ca5-ff8254c83906@oracle.com>
 <bb392778-7331-3163-30d7-31d45cd612f2@oracle.com>
 <b722afb6-7690-fb8c-2aa2-ee930cfbbb35@oracle.com>
 <B55D9B6C-9E26-422E-9766-2181A14A22F2@oracle.com>
Message-ID: <58adeaec-8e3e-02f8-a19f-b4863ddc6e73@oracle.com>

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.


From conor.cleary at oracle.com  Fri Jul 31 15:16:02 2020
From: conor.cleary at oracle.com (Conor Cleary)
Date: Fri, 31 Jul 2020 16:16:02 +0100
Subject: RFR[8246707]: '(sc) SocketChannel.read/write throws
 AsynchronousCloseException on closed channel'
In-Reply-To: <6075867e-ef0f-86e4-4849-1341aa3d68f8@oracle.com>
References: <3ab365e5-ea96-aee1-bbb3-a24d301e5169@oracle.com>
 <6075867e-ef0f-86e4-4849-1341aa3d68f8@oracle.com>
Message-ID: <b179a121-052a-065d-4afd-cf0c3632832a@oracle.com>

Hi guys,

If you have a minute could you take a look at my new webrev for 
JDK-8246707 '(sc) SocketChannel.read/write throws 
AsynchronousCloseException on closed channel'?

I updated the revision to include ensureOpenAndConnected() checks for 
blockingRead, blockingWriteFully and sendOutOfBandData before checking 
the blocking mode. Also, a test to check that a ClosedChannelException 
is thrown for read and write operations on a closed SocketChannel is now 
included (ReadWriteAfterClose.java).

Thanks!

bug: https://bugs.openjdk.java.net/browse/JDK-8246707
webrev: 
http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246707/webrevs/webrev.05/

On 16/07/2020 17:26, Alan Bateman wrote:
> On 16/07/2020 17:03, Conor Cleary wrote:
>>
>> Hi all,
>>
>> Could someone please take a look at my webrev for JDK-8246707 '(sc) 
>> SocketChannel.read/write throws AsynchronousCloseException on closed 
>> channel'?
>>
>> This fix addresses an issue where an AsynchronousCloseException was 
>> being thrown instead of a ChannelClosedException when 
>> SocketChannel.write() is called on a /closed/ SocketChannel.
>>
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8246707
>> webrev: 
>> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246707/webrevs/webrev.02/
>>
> Thanks for this, this was an oversight when this code was refactored. 
> It's not technically wrong to throw a sub-class of 
> ChannelClosedException but AsynchronousCloseException could indeed be 
> confusion. Are you planning to include a test? It may be that some of 
> the existing tests to check that ChannelClosedException is thrown on a 
> closed channel could be updated to check that the exception is not 
> AsynchronousCloseException.
>
> As regards the change, then for consistency I would like to see 
> blockingRead, blockingWriteFully and sendOutOfBandData also call 
> ensureOpenAndConnected before checking the blocking mode. That will 
> keep them consistent with read/write. Also the beginWrite(true) in 
> blockingWriteFully should be inside the try block rather than outside 
> (okay if that is done as a separate issue if needed but it's all in 
> the same area so I mention it here).
>
> -Alan.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200731/8d8d930f/attachment.htm>

From Alan.Bateman at oracle.com  Fri Jul 31 17:26:20 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 31 Jul 2020 18:26:20 +0100
Subject: RFR[8246707]: '(sc) SocketChannel.read/write throws
 AsynchronousCloseException on closed channel'
In-Reply-To: <b179a121-052a-065d-4afd-cf0c3632832a@oracle.com>
References: <3ab365e5-ea96-aee1-bbb3-a24d301e5169@oracle.com>
 <6075867e-ef0f-86e4-4849-1341aa3d68f8@oracle.com>
 <b179a121-052a-065d-4afd-cf0c3632832a@oracle.com>
Message-ID: <d7054277-9c17-4835-2f74-6c310a0d8f34@oracle.com>

On 31/07/2020 16:16, Conor Cleary wrote:
>
> Hi guys,
>
> If you have a minute could you take a look at my new webrev for 
> JDK-8246707 '(sc) SocketChannel.read/write throws 
> AsynchronousCloseException on closed channel'?
>
> I updated the revision to include ensureOpenAndConnected() checks for 
> blockingRead, blockingWriteFully and sendOutOfBandData before checking 
> the blocking mode. Also, a test to check that a ClosedChannelException 
> is thrown for read and write operations on a closed SocketChannel is 
> now included (ReadWriteAfterClose.java).
>
> Thanks!
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8246707
> webrev: 
> http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8246707/webrevs/webrev.05/
>
Does the test fail without the changes? I'm asking because I assume 
TestNG assertThrows(CCE, ...) will not fail when a sub-class of CCE is 
thrown.

The changes to SocketChannelImpl look correct. One other thing is the 
beginWrite at L1264 should be in try-finally block, not before. Minor 
nit the comment at L1178 is for the isBlocking check, meaning 
ensureOpenAndConnected should be before comment rather than after. I'd 
prefer if there was an empty line after the ensureOpenAndConnect in both 
blockingRead and blockingWriteFully to keep the style consistent.

-Alan.

From stefan.reich.maker.of.eye at googlemail.com  Tue Jul 14 09:12:55 2020
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Tue, 14 Jul 2020 09:12:55 -0000
Subject: File locking supported on all platforms?
In-Reply-To: <d06b746d-bdb2-371e-eb79-8d72aedfc591@yawk.at>
References: <CAC2-jLHDQXse9e8pQwV6sTHuqMUoopFjpHgb=Nnq+ZHNUe5UsA@mail.gmail.com>
 <80e8368e-cf3e-2ba7-e7ff-70408739023b@yawk.at>
 <CAC2-jLHwkVzHQcNtsF5xhjA-4=dnLn-wiYb3=9XMNwdmagTohQ@mail.gmail.com>
 <e6d6f4ec-49cc-da45-efe6-41cc1b92ecbd@yawk.at>
 <CAC2-jLEHovzdJPm=8Ch_g8ppHVxxV6RzTxpeWpFQWfuNJS6fSA@mail.gmail.com>
 <d06b746d-bdb2-371e-eb79-8d72aedfc591@yawk.at>
Message-ID: <CAC2-jLGSZXZ1fn1reQgpavw-0JnM1mOjtejTyOOJMjmGOve=Nw@mail.gmail.com>

OK so I'll have to go all the way and do a two-JVM-test to be sure. I
assume though that in normal desktop user set-ups, we'll be good anyways.

Thanks

On Sat, 11 Jul 2020 at 16:13, Jonas Konrad <me at yawk.at> wrote:

> I asked around and apparently fcntl locking can be idempotent in the
> same process at least for some fs, so locking twice in the same jvm may
> not error even on an fs that does support locks.
>
> - Jonas
>
> On 7/11/20 12:13 PM, Stefan Reich wrote:
> > Hmm that's what I feared. So to be really sure I should do an actual
> > test. Maybe I can get away with doing two locks on the same file within
> > one JVM for testing the feature? I should try that.
> >
> > Thanks
> >
> > On Sat, 11 Jul 2020 at 12:10, Jonas Konrad <me at yawk.at
> > <mailto:me at yawk.at>> wrote:
> >
> >     I think it should just fail silently / without error, that's what
> fcntl
> >     does at least. I'm not sure if there's a good way to determine
> whether
> >     locking will actually work.
> >
> >     - Jonas
> >
> >     On 7/11/20 11:47 AM, Stefan Reich wrote:
> >      > Hi Jonas,
> >      >
> >      > what would happen if I try to lock a file on these platforms? Can
> I
> >      > reliably detect this case? That would already help a lot.
> >      >
> >      > The use case is ensuring a database's consistency which I now do
> >     over a
> >      > socket protocol, but file locks would be faster and more reliable.
> >      >
> >      > Stefan
> >      >
> >      > On Sat, 11 Jul 2020 at 11:45, Jonas Konrad <me at yawk.at
> >     <mailto:me at yawk.at>
> >      > <mailto:me at yawk.at <mailto:me at yawk.at>>> wrote:
> >      >
> >      >     Hey,
> >      >
> >      >     Some file systems on Linux, eg old NFS, do not support
> >     locking at all.
> >      >
> >      >     - Jonas
> >      >
> >      >     On 7/11/20 11:36 AM, Stefan Reich wrote:
> >      >      > Hi,
> >      >      >
> >      >      > a quick question regarding file locks in Java. I seem to
> >     remember
> >      >      > reading somewhere that this feature isn't guaranteed to
> >     work on all
> >      >      > platforms. However, I can now find no mention of that e.g.
> >     here
> >      >      >
> >      >
> >       <
> https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileLock.html
> >.
> >      >      >
> >      >      > The page does list that numerous special assumptions may
> >     fail, for
> >      >      > example that programs which /don't/ lock a file are
> >     prevented from
> >      >      > changing it when it is locked by another program.
> >      >      >
> >      >      > However, I only care about the basic feature, namely that
> one
> >      >     local file
> >      >      > cannot be locked by two Java programs at once and will
> >     cause one
> >      >     of them
> >      >      > to throw an exception.
> >      >      >
> >      >      > Is this guaranteed to work everywhere?
> >      >      >
> >      >      > Many greetings
> >      >      > Stefan
> >      >      >
> >      >      > --
> >      >      > Stefan Reich
> >      >      > BotCompany.de // Java-based operating systems
> >      >
> >      >
> >      >
> >      > --
> >      > Stefan Reich
> >      > BotCompany.de // Java-based operating systems
> >
> >
> >
> > --
> > Stefan Reich
> > BotCompany.de // Java-based operating systems
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200714/cd5797fa/attachment-0001.htm>