Re: Unix domain sockets (UDS, AF_UNIX) in System.inheritedChannel() and elsewhere in Java

[Alan Bateman]

On 19/07/2019 16:35, František Kučera wrote:


Hello,

I am interested in the unix domain sockets (UDS, AF_UNIX) support in Java.

Java is able to inherit a channel from the parent process and access 
it through System.inheritedChannel(). The channel is passed as an open 
file descriptor (FD) to Java form the parent process which is usually 
some superserver (like xinetd or systemd) or some other loader*. The 
channel might be both a ServerSocketChannel (accept() is called in 
Java) and a SocketChannel (accept() is called once in the parent 
process) or a DatagramChannel. And it might be TCP, UDP or UDS. But 
the UDS support is a bit incomplete.


I want to make the UDS support better so I wrote a proof-of-concept 
patch – see attached .diff and webrev: 
http://frantovo.cz/disk/openjdk-uds-08/ It still requires a lot of 
work (clean-up, refactoring, portability, security manager, 
documentation, testing…) but it seems feasible to me.


What already works in Java:

  * listening on an inherited UDS channel (ServerSocketChannel) – e.g.
Jetty or Tomcat are able to listen and serve HTTP requests on UDS
instead of TCP
  * receiving datagrams from UDS

What my proof-of-concept patch adds:

  * class UnixSocketAddress extends SocketAddress
  * support also for a single inherited UDS connection (SocketChannel)
  * getting correct local and remote addresses (instead of an
InetAddress with some random IP and port)
  * creating new server and client UDS channels from Java

I am looking for a sponsor/mentor who will help me finish this task 
through wise advice and peer review.


My further plans:

  * finish the datagram part (sending responses to UDS does not work yet)
  * allow inheritance of multiple channels/sockets
  * getting client credentials (user name and group – where available)
  * maybe passing FDs through UDS (where available)
  * maybe FileChannel for accessing ordinary files inherited from the
parent as FDs

This is something that we've prototyped several times over the years but 
never came to a conclusion on whether to attempt to include it or not.


No objection to exploring it again but I think it should be prototyped 
as a JDK-specific API, probably jdk.net module. This is the approach we 
have been discussing on nio-dev for the RDMA socket API. In terms of API 
then introducing a SocketAddress sub-class for Unix domain sockets looks 
right, although it should probably be created with a Path or String 
rather than a byte array. For the RDMA sockets we have a factory class 
to create SocketChannel or ServerSocketChannels that will probably work 
here too.


Windows and pipes is something that is worth discussing too as we didn't 
do anything on that in previous explorations.


-Alan

Unix domain sockets (UDS, AF_UNIX) in System.inheritedChannel() and elsewhere in Java

[František Kučera]

Hello,

I am interested in the unix domain sockets (UDS, AF_UNIX) support in Java.

Java is able to inherit a channel from the parent process and access it 
through System.inheritedChannel(). The channel is passed as an open file 
descriptor (FD) to Java form the parent process which is usually some 
superserver (like xinetd or systemd) or some other loader*. The channel 
might be both a ServerSocketChannel (accept() is called in Java) and a 
SocketChannel (accept() is called once in the parent process) or a 
DatagramChannel. And it might be TCP, UDP or UDS. But the UDS support is 
a bit incomplete.


I want to make the UDS support better so I wrote a proof-of-concept 
patch – see attached .diff and webrev: 
http://frantovo.cz/disk/openjdk-uds-08/ It still requires a lot of work 
(clean-up, refactoring, portability, security manager, documentation, 
testing…) but it seems feasible to me.


What already works in Java:

 * listening on an inherited UDS channel (ServerSocketChannel) – e.g.
   Jetty or Tomcat are able to listen and serve HTTP requests on UDS
   instead of TCP
 * receiving datagrams from UDS

What my proof-of-concept patch adds:

 * class UnixSocketAddress extends SocketAddress
 * support also for a single inherited UDS connection (SocketChannel)
 * getting correct local and remote addresses (instead of an
   InetAddress with some random IP and port)
 * creating new server and client UDS channels from Java

I am looking for a sponsor/mentor who will help me finish this task 
through wise advice and peer review.


My further plans:

 * finish the datagram part (sending responses to UDS does not work yet)
 * allow inheritance of multiple channels/sockets
 * getting client credentials (user name and group – where available)
 * maybe passing FDs through UDS (where available)
 * maybe FileChannel for accessing ordinary files inherited from the
   parent as FDs

Franta

*) might be just few lines in C e.g. https://blog.frantovo.cz/c/372/#toc_12

diff -r cff8aad2593f src/java.base/share/classes/java/net/ProtocolFamily.java
--- a/src/java.base/share/classes/java/net/ProtocolFamily.java	Fri Jul 19 16:25:04 2019 +0300
+++ b/src/java.base/share/classes/java/net/ProtocolFamily.java	Fri Jul 19 17:11:56 2019 +0200
@@ -27,6 +27,8 @@
 
 /**
  * Represents a family of communication protocols.
+ * 
+ * @see StandardProtocolFamily
  *
  * @since 1.7
  */
diff -r cff8aad2593f src/java.base/share/classes/java/net/StandardProtocolFamily.java
--- a/src/java.base/share/classes/java/net/StandardProtocolFamily.java	Fri Jul 19 16:25:04 2019 +0300
+++ b/src/java.base/share/classes/java/net/StandardProtocolFamily.java	Fri Jul 19 17:11:56 2019 +0200
@@ -41,5 +41,12 @@
 /**
  * Internet Protocol Version 6 (IPv6)
  */
-INET6
+INET6,
+
+/**
+ * Unix domain sockets (AF_UNIX / AF_LOCAL)
+ *
+ * @see UnixSocketAddress
+ */
+UNIX
 }
diff -r cff8aad2593f src/java.base/share/classes/java/net/UnixSocketAddress.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +
+++ b/src/java.base/share/classes/java/net/UnixSocketAddress.java	Fri Jul 19 17:11:56 2019 +0200
@@ -0,0 +1,60 @@
+package java.net;
+
+import java.util.Arrays;
+
+/**
+ * Immutable representation of a AF_UNIX address.
+ * 
+ * TODO: methods for detection of abstract addresses
+ * 
+ * @see StandardProtocolFamily#UNIX
+ * @author Ing. Frantisek Kucera (frantovo.cz)
+ */
+public class UnixSocketAddress extends SocketAddress {
+
+private static final long serialVersionUID = 1l;
+
+private final byte[] path;
+
+/**
+ * Empty address -- used in case of unix domain socket client.
+ */
+public UnixSocketAddress() {
+this.path = null;
+}
+
+/**
+ * @param path raw path bytes in the platform encoding
+ */
+public UnixSocketAddress(byte[] path) {
+this.path = Arrays.copyOf(path, path.length);
+}
+
+/**
+ * @param path String representation of the socket's path
+ */
+public UnixSocketAddress(String path) {
+this.path = path.getBytes();
+}
+
+/**
+ * @return String representation of the socket's path
+ */
+public String getPath() {
+return path == null ? null : new String(path);
+}
+
+/**
+ *
+ * @return original representation of the socket's path
+ */
+public byte[] getPathBytes() {
+return path == null ? null : Arrays.copyOf(path, path.length);
+}
+
+@Override
+public String toString() {
+return getClass().getSimpleName() + ": " + getPath();
+}
+
+}
diff -r cff8aad2593f src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java
--- a/src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java	Fri Jul 19 16:25:04 2019 +0300
+++ b/src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java	Fri Jul 19 17:11:56 2019 +0200
@@ -26,6 +26,7 @@
 package java.nio.channels;
 
 import java.io.IOException;
+import java.net.ProtocolFamily;
 impor

RFR 6563286 6797318 8177648 - Undeclared IAE thrown from HttpURLConnection.connect for some URLs

[Jaikiran Pai]

Hello,

Could I please get a review and a sponsor for a patch which fixes an
issue in sun.net.spi.DefaultProxySelector? The patch is available as a
webrev at
http://cr.openjdk.java.net/~jpai/webrev/defaultproxyselector/1/webrev/

The issue has been reported in multiple different JBS issues[1][2][3]
all coming back to the same root cause. There probably are other similar
JBS issues related to this. The root cause is that the
DefaultProxySelector throws IllegalArgumentException when the passed URI
is non-null and thus contradicts its javadoc which (only) states the
IllegalArgumentException is thrown when the URI is null.

The change in the patch, now returns a Proxy.NO_PROXY when either the
protocol or the host of the passed URI is null. This is the same as
what's suggested in JDK-6797318.

In addition to the change to DefaultProxySelector, this patch also
changes sun.net.www.protocol.http.HttpURLConnection and
sun.net.www.protocol.ftp.FtpURLConnection. Just before invoking the
ProxySelector.select(...), both these classes use
sun.net.www.ParseUtil.toURI(...) which can return null. The changes to
these classes now ensure that the null isn't passed to the selector (to
avoid a IllegalArgumentException) and instead is handled properly.

2 new test classes have been added in the patch. These tests fail (as
expected) without the change to the source classes above and pass with
these changes. After these changes, locally, I have also run the
existing jtreg tests under test/jdk/java/net/HttpURLConnection and
test/jdk/sun/net/www/http/HttpURLConnection/ and they have passed
without regressions.

I haven't added anything new for the FTP testing, since I didn't find a
easy way to do that (based on my very limited search of existing tests).

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

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

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

-Jaikiran

Re: RFR: 8228394: Cleanup unused java.net SharedSecrets classes

[Claes Redestad]

On 2019-07-19 15:28, Chris Hegarty wrote:

Nice cleanup! Reviewed.


Thanks for reviewing, Chris!

/Claes

Re: RFR: 8228394: Cleanup unused java.net SharedSecrets classes

[Chris Hegarty]

> On 19 Jul 2019, at 13:51, Claes Redestad  wrote:
> 
> Hi,
> 
> please review this cleanup to remove a few java.net access objects that
> are no longer in use.
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8228394/open.00/
> Bug:https://bugs.openjdk.java.net/browse/JDK-8228394

Nice cleanup! Reviewed.

-Chris.

Re: RFR: 8228394: Cleanup unused java.net SharedSecrets classes

[Claes Redestad]

On 2019-07-19 15:01, Alan Bateman wrote:

This looks good to me.


Thanks for reviewing, Alan!

/Claes

Re: RFR: 8228394: Cleanup unused java.net SharedSecrets classes

[Alan Bateman]

On 19/07/2019 13:51, Claes Redestad wrote:

Hi,

please review this cleanup to remove a few java.net access objects that
are no longer in use.

Webrev: http://cr.openjdk.java.net/~redestad/8228394/open.00/
Bug:    https://bugs.openjdk.java.net/browse/JDK-8228394

(One usage was from sun.misc.ClassLoaderUtil, removed by 
https://bugs.openjdk.java.net/browse/JDK-8034853, which seems

to have forgotten to remove a related and now unused test.jar
file. I removed this too and verified all tests pass.)

This looks good to me.

RFR: 8228394: Cleanup unused java.net SharedSecrets classes

[Claes Redestad]

Hi,

please review this cleanup to remove a few java.net access objects that
are no longer in use.

Webrev: http://cr.openjdk.java.net/~redestad/8228394/open.00/
Bug:https://bugs.openjdk.java.net/browse/JDK-8228394

(One usage was from sun.misc.ClassLoaderUtil, removed by 
https://bugs.openjdk.java.net/browse/JDK-8034853, which seems

to have forgotten to remove a related and now unused test.jar
file. I removed this too and verified all tests pass.)

Testing: tier1+2

Thanks!

/Claes

RE: RFR : 8227737: avoid implicit-function-declaration on AIX

[Baesken, Matthias]

Thanks for  the additional review !

Best regards, Matthias

From: Lindenmaier, Goetz
Sent: Freitag, 19. Juli 2019 09:33
To: Baesken, Matthias ; Schmidt, Lutz 
; Doerr, Martin 
Subject: RE: RFR : 8227737: avoid implicit-function-declaration on AIX

Hi Matthias,

This looks good, thanks for doing this.

Best regards,
  Goetz.


From: Langer, Christoph
Sent: Mittwoch, 17. Juli 2019 09:40
To: Baesken, Matthias 
mailto:matthias.baes...@sap.com>>; Java Core Libs 
mailto:core-libs-...@openjdk.java.net>>; 
nio-...@openjdk.java.net; 
net-dev@openjdk.java.net; 
awt-...@openjdk.java.net
Cc: 'ppc-aix-port-...@openjdk.java.net' 
mailto:ppc-aix-port-...@openjdk.java.net>>
Subject: RE: RFR : 8227737: avoid implicit-function-declaration on AIX

Hi Matthias,

looks good, thanks for doing this.

How far are we then from enabling "warnings as errors" on AIX? :P

Best regards
Christoph

From: awt-dev 
mailto:awt-dev-boun...@openjdk.java.net>> On 
Behalf Of Baesken, Matthias
Sent: Dienstag, 16. Juli 2019 17:04
To: Java Core Libs 
mailto:core-libs-...@openjdk.java.net>>; 
nio-...@openjdk.java.net; 
net-dev@openjdk.java.net; 
awt-...@openjdk.java.net
Cc: 'ppc-aix-port-...@openjdk.java.net' 
mailto:ppc-aix-port-...@openjdk.java.net>>
Subject: [CAUTION]  RFR : 8227737: avoid implicit-function-declaration 
on AIX

Hello, please review the following  AIX related change .
It fixes a number of  missing inclusions  leading to  
implicit-function-declaration  warnings when compiling  with the recent xlc16 
/xlclang .


At various places in the native C coding in jdk, we miss header inclusions on 
AIX.
This leads to warnings like :

/nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: warning: 
implicitly declaring library function 'snprintf'
with type 'int (char *, unsigned long, const char *, ...)' 
[-Wimplicit-function-declaration]
snprintf(aix_fd_dir, 32, "/proc/%d/fd", getpid());
^
/nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: note: include 
the header  or explicitly provide a declaration for 'snprintf'

or

/nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: warning: 
implicitly declaring library function 'memset'
with type 'void *(void *, int, unsigned long)' [-Wimplicit-function-declaration]
memset((void *)info, 0, sizeof(Dl_info));

/nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: note: include 
the header  or explicitly provide a declaration for 'memset'



Bug/webrev :

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

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


Thanks, Matthias