I installed java-1.8.0-openjdk, java-1.8.0-openjdk-devel, java-1.8.0-openjdk-headless version 1:1.8.0.242.b08-0.fc31 from 'updates' repo. Simple java calls e.g. to get the current ip address fail, the runtime throws NPEs immediately at startup, e.g. Caused by: java.lang.NullPointerException at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1847) 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) A quick check with Oracles jdk1.8.0_241 shows that everything works fine with my project. A simple downgrade to 1:1.8.0.222.b10-1.fc31 of the 'fedora' repos is also fine. So, there must be sth. wrong with the current 242 rpm? Any help is appreciated
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!