This bug entry acts as a parent node for all bugs related to support certain Java 11+ features on top of Bug 1636 I leave references for this issue: Related Reading / Overview - https://blog.joda.org/2018/09/from-java-8-to-java-11.html - https://blog.joda.org/search/label/modules Related JEPs - http://openjdk.java.net/jeps/220 Modular JRE - http://openjdk.java.net/jeps/260 Encapsulation - http://openjdk.java.net/jeps/238 Multi-Release JAR Files - http://openjdk.java.net/jeps/282 jlink (the Java linker) - http://openjdk.java.net/jeps/261 Module System ++++ Please note that: - Both, Java-8 and Java-11 have LTS (long time support) - We will not test against Java-9 nor Java-10: Already outdated - Oracle's Java build's are no more licensed for commercial use beyond Java-8 - We will only test & use OpenJDK builds starting with Java-11
.. on top of Bug 1363
Will the eventual 2.4.0 release jars include "Automatic-Module-Name" entries in their manifests? (This is described by one of your Related Reading links: https://blog.joda.org/search/label/modules.) The 2.4.0-rc-20200202 jars (not the fat jar, but the gluegen-rt and jogl-all jars) currently don't work when they are put on the modulepath, where they are treated as automatic modules. Java makes up module names based on the jar filenames ... and Java's heuristic gives the same module name for both "jogl-all-2.4.0-rc-20200202.jar" and "jogl-all-2.4.0-rc-20200202-natives-linux-amd64.jar". (The heuristic scans until it finds the first hyphen-then-digit, and assumes the rest of the filename is a version -- the automatic module name for both jars is "jogl.all".) This could be addressed by putting "Automatic-Module-Name" entries in the jar manifests.
(In reply to Mike Hogye from comment #2) Re "Automatic-Module-Name", thank you Mike! Can you create a new bug entry and make it a child of this parent entry. We certainly can change things for the manifest, if they are backward compatible to Java8 .. (should be). While I don't see jar files such as "jogl-all-2.4.0-rc-20200202-natives-linux-amd64.jar", i.e. added version tag '2.4.0-rc-date' but this hints to the native lib loading via this auto-module feature? Hence it is not so much relevant to the 'fat jar'? Please open the new bug entry, elaborate and link to these two comments. If it is helping .. why not? You may also propose a tested git patch ... Thank you.
(In reply to Sven Gothel from comment #3) Added Bug 1425, which clarifies what I meant about the jar filenames.
I get this when I run an example using Java 17 build 35: Exception in thread "main" java.lang.UnsatisfiedLinkError: /tmp/jogamp_0000/file_cache/jln3159141199686910866/jln18332382328256781421/natives/linux-amd64/libnativewindow_awt.so: /home/gouessej/Documents/installation/jdk-17/lib/libjawt.so: version `SUNWprivate_1.1' not found (required by /tmp/jogamp_0000/file_cache/jln3159141199686910866/jln18332382328256781421/natives/linux-amd64/libnativewindow_awt.so) at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:384) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:228) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:170) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2389) at java.base/java.lang.Runtime.load0(Runtime.java:755) at java.base/java.lang.System.load(System.java:1953) at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:603) at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:63) at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:106) at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:487) at jogamp.nativewindow.NWJNILibLoader.access$000(NWJNILibLoader.java:39) at jogamp.nativewindow.NWJNILibLoader$1.run(NWJNILibLoader.java:49) at jogamp.nativewindow.NWJNILibLoader$1.run(NWJNILibLoader.java:41) at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) at jogamp.nativewindow.NWJNILibLoader.loadNativeWindow(NWJNILibLoader.java:41) at jogamp.nativewindow.jawt.JAWTUtil.<clinit>(JAWTUtil.java:336) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:467) at com.jogamp.nativewindow.NativeWindowFactory$3.run(NativeWindowFactory.java:344) at com.jogamp.nativewindow.NativeWindowFactory$3.run(NativeWindowFactory.java:340) at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) at com.jogamp.nativewindow.NativeWindowFactory.initSingleton(NativeWindowFactory.java:340) at com.jogamp.opengl.GLProfile.initProfilesForDefaultDevices(GLProfile.java:1721) at com.jogamp.opengl.GLProfile.access$000(GLProfile.java:80) at com.jogamp.opengl.GLProfile$1.run(GLProfile.java:230) at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) at com.jogamp.opengl.GLProfile.initSingleton(GLProfile.java:216) at com.jogamp.opengl.GLProfile.getProfileMap(GLProfile.java:2297) at com.jogamp.opengl.GLProfile.get(GLProfile.java:1021) at com.jogamp.opengl.GLProfile.get(GLProfile.java:1050) at com.jogamp.opengl.GLProfile.getMaximum(GLProfile.java:756) at com.ardor3d.framework.jogl.CapsUtil.getProfile(CapsUtil.java:32) at com.ardor3d.framework.jogl.CapsUtil.getCapsForSettings(CapsUtil.java:103) at com.ardor3d.framework.jogl.CapsUtil.getCapsForSettings(CapsUtil.java:50) at com.ardor3d.framework.jogl.awt.JoglAwtCanvas.<init>(JoglAwtCanvas.java:55) at com.ardor3d.framework.jogl.awt.JoglAwtCanvas.<init>(JoglAwtCanvas.java:50) at com.ardor3d.example.canvas.JoglAwtExample.addCanvas(JoglAwtExample.java:153) at com.ardor3d.example.canvas.JoglAwtExample.main(JoglAwtExample.java:105) Is it fixed on the "java11" branch? Is it a known problem?