On 13/02/2014 15:04, Florian Weimer wrote:
Naming is fundamentally different. With that caveat, it would be
possible to expose a socket-based interface, but application code
would have to adhere to the platform naming convention.
When we prototyped this in the past then we used a new Socket
On 02/13/2014 03:23 PM, David M. Lloyd wrote:
Okay, sounds reasonable. The PF_LOCAL protocol family is not available
with Winsock, so I guess it will have to be a separate enum then, with a
single member, although OpenJDK already requires PF_LOCAL support on the
non-Windows platforms.
Windows
On 02/13/2014 07:33 AM, Florian Weimer wrote:
On 02/13/2014 02:21 PM, Alan Bateman wrote:
On 13/02/2014 12:54, Florian Weimer wrote:
Can we add further enumeration values to
java.net.StandardProtocolFamily? The spec does not say so, unlike
javax.lang.model.SourceVersion, and the code in the JD
On 02/13/2014 02:21 PM, Alan Bateman wrote:
On 13/02/2014 12:54, Florian Weimer wrote:
Can we add further enumeration values to
java.net.StandardProtocolFamily? The spec does not say so, unlike
javax.lang.model.SourceVersion, and the code in the JDK expects a
binary flag, so I think the answer
On 13/02/2014 12:54, Florian Weimer wrote:
Can we add further enumeration values to
java.net.StandardProtocolFamily? The spec does not say so, unlike
javax.lang.model.SourceVersion, and the code in the JDK expects a
binary flag, so I think the answer is "no".
Does this mean the expected way
Can we add further enumeration values to
java.net.StandardProtocolFamily? The spec does not say so, unlike
javax.lang.model.SourceVersion, and the code in the JDK expects a binary
flag, so I think the answer is "no".
Does this mean the expected way to add support for further protocol
familie
