Summary: | Support Java 11+ Features (Module Encapsulation, jlink, ..) | ||
---|---|---|---|
Product: | [JogAmp] General | Reporter: | Sven Gothel <sgothel> |
Component: | generic | Assignee: | Sven Gothel <sgothel> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | gouessej, mfery, stacktracer, wwalker3 |
Priority: | P4 | ||
Version: | tbd | ||
Hardware: | All | ||
OS: | all | ||
Type: | FEATURE | SCM Refs: | |
Workaround: | --- | ||
Bug Depends on: | 1425, 1363, 1374 | ||
Bug Blocks: | 1505 |
Description
Sven Gothel
2019-11-30 18:39:08 CET
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? |