Certain forum posts reported various issues using OpenJDK 2x running JogAmp in conjunction with user applications. This in regards to old and new JVM launch parameter like 'add-opens' and the module system, we so far have simply ignored. However, new launch parameter in OpenJDK 2x might also appear which further reduce convenience of mix-and-match libraries, native code and modules. Please add information in this regard under this bug report, so we may be able to address these inconveniences and to keep using OpenJDK for your mixed application feasible. +++ My initial idea of creating a convenient custom launch pack is to use a JVM Launch Pad (JLP, native code or preferably Java itself), which simply adds required parameters to the launched JVM depending on OS and JVM version. Additionally, this JLP could be packed within our JogAmp fat jar file and use an environment variable and/or property setting specifying the actual target main class for the newly launched JVM. This would allow to re-use our JogAmp far jar file to repackage your application by injecting all your libraries and application classes in one jar file and setting mentioned target main class property. The end user then could just launch the application as usual via 'java -jar lala.jar'
Julien: https://forum.jogamp.org/Unable-to-determine-GraphicsConfiguration-tp4042444p4043365.html The use of JNI is going to be more restricted in the future versions of Java (>= 23): https://bugs.openjdk.org/secure/Dashboard.jspa?selectPageId=22205 https://bugs.openjdk.org/browse/JDK-8307341 It will be possible to use "Enable-Native-Access" in the JAR manifest.
Julien: https://forum.jogamp.org/Unable-to-determine-GraphicsConfiguration-tp4042444p4043365.html Modular JARs Maybe there's a solution for your use case: https://openjdk.org/jeps/261#Packaging:-Modular-JAR-files Please can you try to use the manifest attribute "Add-Opens"? https://stackoverflow.com/a/74147550/458157 +++ Sven: When I tried to allows module usage with a hybrid jar file, required jar properties were not allowed for simple class files not build as a module. I simply gave up then, as it ate to much time to continue without a clear direction. Of course, delivering a dual jar file for module and classic-jar usage would be best for all.
Bug 1404 Support Java 11+ Features (Module Encapsulation, jlink, ..)
Julien https://gouessej.wordpress.com/2012/08/01/java-3d-est-de-retour-java-3d-is-back/#commandline Java3D, JogAmp Launch for Java >= 9: ====================================== java --add-opens java.desktop/sun.awt=ALL-UNNAMED -cp j3dcore.jar:j3dutils.jar:vecmath.jar:jogamp-fat.jar:my_awesome_jar.jar my.awesome.App +++ OpenJFX, JogAmp Launch for Java >= 9: ===================================== java –module-path $PATH_TO_FX –add-modules javafx.controls –add-opens javafx.graphics/com.sun.javafx.tk=ALL-UNNAMED –add-opens javafx.graphics/javafx.stage=ALL-UNNAMED –add-opens javafx.graphics/com.sun.javafx.tk.quantum=ALL-UNNAMED –add-opens javafx.graphics/com.sun.glass.ui=ALL-UNNAMED -cp target/classes:jogamp-fat.jar my.awesome.App (perhaps the user module or jar file itself might also need to be added to either the module-list via '-add-modules' or classpath via '-cp')
(In reply to Sven Gothel from comment #4) Julien's OpenJFX launch notes: https://gouessej.wordpress.com/2020/04/05/javafx-et-jogl-fonctionnent-ensemble-javafx-and-jogl-work-together/#commandlineinterface
Current used 'add-opens' in my JogAmp test scripts for Java >= 11, covering all AWT utilization including background erase is: --add-opens java.desktop/sun.awt=ALL-UNNAMED --add-opens java.desktop/sun.awt.windows=ALL-UNNAMED --add-opens java.desktop/sun.java2d=ALL-UNNAMED