Hi Arthur,
The idea looks reasonable to me - I believe the changes in
NetworkInterface.c should be OK.
However - I don't think the changes in net_util.c::DEF_JNI_OnLoad
are acceptable.
I'll question whether this is the right place to bail
out. I agree it would be nice to have some diagnostic
that tells us that the native library is non-functioning
because both IPv4 & IPv6 where not available, but I'd rather
have this check at the place where the code actually tries
to e.g. open an IP/TCP socket, and where throwing a regular exception
with a better detailed message is possible, rather than
having the VM fail to start with some cryptic UnsatisfiedLinkError.
best regards,
-- daniel
On 08/05/2019 06:52, Arthur Eubanks wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8223532
Webrev: http://cr.openjdk.java.net/~aeubanks/8223532/webrev.00/
There are a couple of functions in
src/java.base/unix/native/libnet/NetworkInterface.c which try to create
IPv4 sockets, then check if errno is EPROTONOSUPPORT. If errno is
EPROTONOSUPPORT, then IPv6 is tried, else it immediately bails.
We have a kernel that returns EAFNOSUPPORT when IPv4 is disabled and
there is an attempt to create an AF_INET socket.
Rather than adding a check for EAFNOSUPPORT, which seems too specific,
just don't bother trying to create an IPv4 socket if IPv4 is not
available. This uses ipv4_available(), introduced in
http://hg.openjdk.java.net/jdk/jdk/rev/22323f20401b.
Since previously the code assumed that we have at least IPv4, now when
initializing ipv4/6_available(), make sure that at least one of them is
available, or else bail. One problem I have with this is that the error
message when neither is present is not descriptive:
Error occurred during initialization of boot layer
java.lang.UnsatisfiedLinkError: unsupported JNI version 0xFFFFFFFF
required by path/to/jdk/build/jdk/lib/libnet.so
