Bug 1805105

Hi, would you be able provide a test case/program that causes this?

I'll add a demo.zip as attachment.
To get the error, do the following:

cd Demo/target/Demo-0.0.1-SNAPSHOT-cri
java -jar Demo-0.0.1-SNAPSHOT.jar

As stated above, the different results:
- oracle-1.8u241: ok
- open-1.8u222:   ok
- open-1.8u242:   not ok, NPEs

What i figured out already: the culprit seems to be my method setLibraryPath() (in application.java)
Without this construct, all java runtimes do the same (successfully). 
With this method active, only openjdk u242 has errors.

Created attachment 1664564 [details]
demo.zip

This is what function setLibraryPath() in Application.java does:

	public static void setLibraryPath() {
		System.setProperty("java.library.path", LIB_PATH);
		// Setting the lib path does not work like so, because it is being
		// cached. Workaround:
		// The Classloader has a static field (sys_paths) that contains the
		// paths. If that field is set to null, it is initialized automatically.
		// Therefore forcing that field to null will result into the
		// reevaluation of the library path as soon as loadLibrary() is called
		Field fieldSysPath;
		try {
			fieldSysPath = ClassLoader.class.getDeclaredField("sys_paths");
			fieldSysPath.setAccessible(true);
			fieldSysPath.set(null, null);
			LOGGER.info("Setting java.library.path to: " + LIB_PATH);
		} catch (NoSuchFieldException | SecurityException | IllegalArgumentException | IllegalAccessException e) {
			LOGGER.error("Unable to set library path", e);
		}
	}

So you're reflectively setting an internal field of ClassLoader to null and expect this to work. FWIW, you are actually setting sun.boot.library.path to null.

With OpenJDK 8u242, JDK-8194653 (or JDK-8231584) is included which changes internals slightly to break your application code. In fact, if I turn on system assertions with your app it triggers an assertion first:

$ java -esa -jar target/Demo-0.0.1-SNAPSHOT-cri/Demo-orig.jar
21.02.2020-10:31:13 INFO  - Application                              - Initializing application
21.02.2020-10:31:13 INFO  - Application                              - Setting java.library.path to: ./lib
21.02.2020-10:31:13 INFO  - Application                              - Launching Application.
Exception in thread "main" java.lang.AssertionError: should be initialized at this point
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
	at java.lang.Runtime.loadLibrary0(Runtime.java:871)
	at java.lang.System.loadLibrary(System.java:1124)
	at java.net.InetAddress$1.run(InetAddress.java:295)
	at java.net.InetAddress$1.run(InetAddress.java:293)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.InetAddress.<clinit>(InetAddress.java:292)
	at app.client.Application.getLocalHost(Application.java:35)
	at app.client.Application.main(Application.java:44)

Your code worked/works with 8u222, since the impl details of ClassLoader still were as described by the "workaround" in your application code. This is nothing that can be relied on.

TLDR; You should NOT change system internals reflectively. As noticed, this may break any time on JDK version update.

Why aren't you setting java.library.path via the command line like so? That's well defined behavor.

$ java -Djava.library.path=./lib -jar ...

Example (with setLibraryPath() commented out):

$ java -Djava.library.path=./lib -XshowSettings:properties -esa -jar target/Demo-0.0.1-SNAPSHOT-cri/Demo-0.0.1-SNAPSHOT.jar 
Property settings:
    awt.toolkit = sun.awt.X11.XToolkit
    file.encoding = UTF-8
    file.encoding.pkg = sun.io
    file.separator = /
    java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
    java.awt.printerjob = sun.print.PSPrinterJob
    java.class.path = target/Demo-0.0.1-SNAPSHOT-cri/Demo-0.0.1-SNAPSHOT.jar
    java.class.version = 52.0
    java.endorsed.dirs = /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.fc30.x86_64/jre/lib/endorsed
    java.ext.dirs = /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.fc30.x86_64/jre/lib/ext
        /usr/java/packages/lib/ext
    java.home = /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.fc30.x86_64/jre
    java.io.tmpdir = /tmp
    java.library.path = ./lib
    java.runtime.name = OpenJDK Runtime Environment
    java.runtime.version = 1.8.0_242-b08
    java.specification.name = Java Platform API Specification
    java.specification.vendor = Oracle Corporation
    java.specification.version = 1.8
    java.vendor = Oracle Corporation
    java.vendor.url = http://java.oracle.com/
    java.vendor.url.bug = http://bugreport.sun.com/bugreport/
    java.version = 1.8.0_242
    java.vm.info = mixed mode
    java.vm.name = OpenJDK 64-Bit Server VM
    java.vm.specification.name = Java Virtual Machine Specification
    java.vm.specification.vendor = Oracle Corporation
    java.vm.specification.version = 1.8
    java.vm.vendor = Oracle Corporation
    java.vm.version = 25.242-b08
    line.separator = \n 
    os.arch = amd64
    os.name = Linux
    os.version = 5.4.18-100.fc30.x86_64
    path.separator = :
    sun.arch.data.model = 64
    sun.boot.class.path = /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.fc30.x86_64/jre/lib/resources.jar
        /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.fc30.x86_64/jre/lib/rt.jar
        /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.fc30.x86_64/jre/lib/sunrsasign.jar
        /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.fc30.x86_64/jre/lib/jsse.jar
        /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.fc30.x86_64/jre/lib/jce.jar
        /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.fc30.x86_64/jre/lib/charsets.jar
        /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.fc30.x86_64/jre/lib/jfr.jar
        /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.fc30.x86_64/jre/classes
    sun.boot.library.path = /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.fc30.x86_64/jre/lib/amd64
    sun.cpu.endian = little
    sun.cpu.isalist = 
    sun.io.unicode.encoding = UnicodeLittle
    sun.java.command = target/Demo-0.0.1-SNAPSHOT-cri/Demo-0.0.1-SNAPSHOT.jar
    sun.java.launcher = SUN_STANDARD
    sun.jnu.encoding = UTF-8
    sun.management.compiler = HotSpot 64-Bit Tiered Compilers
    sun.os.patch.level = unknown
    user.country = US
    user.dir = /home/sgehwolf/Documents/openjdk/bugs/rhbz_bugs/rhbz1805105-8u242-regression/reproducer/Demo
    user.home = /home/sgehwolf
    user.language = en
    user.name = sgehwolf
    user.timezone = 

21.02.2020-10:43:57 INFO  - Application                              - Initializing application
21.02.2020-10:43:57 INFO  - Application                              - Launching Application.
21.02.2020-10:43:57 INFO  - Application                              - Host: t580-laptop (192.168.1.18)


This is application code is changing JDK internals, breaking invariants. Thus => not a bug.

Thank you very much for this detailled information!!!
(continue doing so, this does not happen often!)

Ok, i understand what's happening,
the originial idea was to not use commandline params (multiple reasons) but if this is the official way, well... my clients corporate framework libraries use the exact same approach of code, i'll have some consulting to do now ... ;-)

Anyway, thanks again for the references and context!