Unable to determine GraphicsConfiguration

I have no solution to suggest to make JogAmp work with an executable JAR and Java >=9. However, the deployment methods allowing to use any command line arguments should work: PackR, Jlink + JPackage, JNDT (my own tool).

I'll try what the eclipse runnable jar-in-jar runner can do with classpath libraries.
Seems like eclipse jar-in-jar runner cannot deal with command line arguments.

I still have the requirement that the deployment does not require any extract but runs directly from the runnable .jar with double click.
I mean the file must be able to be downloaded and ran directly, no install or actual deployment.

final command for running directly from .jar package without deployment, extraction or installation:
java --add-exports java.base/java.lang=ALL-UNNAMED --add-exports java.desktop/sun.java2d=ALL-UNNAMED --add-opens java.desktop/sun.awt=ALL-UNNAMED --add-opens java.desktop/sun.awt.windows=ALL-UNNAMED -jar joglrenderengine.jar

edit: one remotely acceptable solution is to have a run.bat and run.sh with the distribution package or inside the jar.

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.

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

Custom MANIFEST.MF without eclipse jar-in-jar loader:

Manifest-Version: 1.0
Add-Exports: java.base/java.lang=ALL-UNNAMED java.desktop/sun.java2d=ALL-UNNAMED
Add-Opens: java.desktop/sun.awt=ALL-UNNAMED java.desktop/sun.awt.windows=ALL-UNNAMED
Main-Class: fi.jkauppa.joglrenderengine.JOGLRenderEngine
Class-Path: ./ jogamp-fat.jar

This results in error:
Error: Could not find or load main class fi.jkauppa.joglrenderengine.JOGLRenderEngine
Caused by: java.lang.NoClassDefFoundError: com/jogamp/opengl/GLEventListener

Default Eclipse manifest with added Add-Exports and Add-Opens lines results in graphicsconfiguration error.

Btw, when the graphics configuration error happens, there will be an extra non-closing java se process thread left running after the main program console closes.

Well I think the module arguments transform the jar run mode to module mode and not classpath mode.

If there is a backward compatible jar manifest config,
I would like to add this to our manifest macros.

(a few months ago I played a little with trying to inject something
to have add-opens alike attributes using our current build
to resolve the module issues - but we would need to move
to modules all the way to be allowed adding some of these
options it seems.)

Sorry but the expected format is very strict, please follow the example on StackOverflow. The "Add-Opens" and "Add-Exports" attributes must be the very first attributes in the file, respect the other constraints too.

Maybe you should use a build tool to get much more flexibility.

I hate build tools so no.

also the specific formatting and order did not change the error output.
also the specification does not say to that to matter, as it should not matter.

Sven Gothel wrote

If there is a backward compatible jar manifest config,
I would like to add this to our manifest macros.

Yes there is. I plan to test it on T.U.E.R first.

Sven Gothel wrote

(a few months ago I played a little with trying to inject something
to have add-opens alike attributes using our current build
to resolve the module issues - but we would need to move
to modules all the way to be allowed adding some of these
options it seems.)

It would probably not allow to open packages in the modules we don't build anyway, am I wrong?

Goofyseeker3 wrote

I hate build tools so no.

Ok but then, you'll have to undergo the limitations of Eclipse build-in tools. By the way, many open source projects use build tools, especially Gradle, Maven, Ant and Bazel.

I especially hate all of those you listed. never.

I rather do things by hand that rely on flakey tools. those listed.

zip with run.bat it is until something better modular appears.

How do you proceed when you have to build an open source project? I admit that they have their bugs and limitations, I personally wasted a lot of time with Maven, Gradle takes age to support very recent versions of Java, Ant is very verbose but very powerful.

When you format your "Add-Opens" clause like this and you move it at the very beginning of the file, does it work?

I tried that exact formatting, no difference. same error, both graphicsconfiguration error and class definition not found, as stated.
I just let the main compiler (IDE) compile the whole thing, java projects dont take long, or even visual studio for c/c#.
there is nothing that requires a separate build tool other than the main compiler. no compiler scripts. other than the IDE packager.

Any tool that I will use is just working, no fiddling around.

edit: most projects using those build tools dont compile easily. so I dont.

Thank you for the feedback. I'll try on a very simple project first when I have some spare time, stay tuned. If I succeed in using those attributes, you'll be able to make an executable JAR with JogAmp as a dependency and I'll improve the wiki.

Sven Gothel wrote

(a few months ago I played a little with trying to inject something
to have add-opens alike attributes using our current build
to resolve the module issues - but we would need to move
to modules all the way to be allowed adding some of these
options it seems.)

You could put module-info.class into META-INF/versions/9/ (it wouldn't break old versions of Java) but I doubt that we can open the packages of modules that we don't build whereas the manifest attributes might allow that, I need to give it a try to confirm.

Bug 1505 - Seamless support of OpenJDK 2x; Mitigating its Constraints and support its Features
https://jogamp.org/bugzilla/show_bug.cgi?id=1505

.. I will add a separate forum post for this.

https://forum.jogamp.org/Bug-1505-Seamless-support-of-OpenJDK-2x-Mitigating-its-Constraints-and-support-its-Features-td4043382.html

+++

Note: 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.

Nice.

a follow up issue. I'm testing out the jogldemos package.
what happened to com.jogamp.opengl.cg.* in jogamp-fat.jar?

did it go the way off the applets in the newer jdk's which is not there?

I have gotten some samples working, including gearsfullscreen,
so its not about not getting anything working, at least.

some examples do not require the usual run parameters:
--add-exports java.base/java.lang=ALL-UNNAMED --add-exports java.desktop/sun.java2d=ALL-UNNAMED --add-opens java.desktop/sun.awt=ALL-UNNAMED  --add-opens java.desktop/sun.awt.windows=ALL-UNNAMED

one such example is demos.es1.angeles.Main. expected behaviour?
I would think that GLES rendering does not require the parameters, but GL rendering does require them, for some reason.
So I would assume only some libraries are affected by the parameter run start-up issue.

demos.swt.Snippet209 does not require the extra launch parameters but it still uses the GL and not GLES.
could you just replace the argument requiring parts of the library with some other non-requiring code.

even most of the glredbook* stuff works, without any parameters, some does not work at all, a few require the launch parameters.
seems like glredbook stuff uses javax.swing and not java.awt mostly.

so the exact issue is java.awt.window not opengl. if using opengl, where is java.awt required.
all java.awt woes are gone if javax.swing is used for all recent java openjdk compatibility.

additional issues:
javabullet references javax.vecmath.Vector3f which is not there for openjdk 17/21, but has actual errors and other missing stuff in code. (java3d has this library.)
demos.nurbs.curveapp.GLListener references com.jogamp.opengl.util.GLUT which is not there.
demos.nurbs.icons.IconFactory references jogamp.opengl.io.StreamUtil which is not there.
demos.nurbs.surfaceapp.GLListener references com.jogamp.opengl.util.glut.gl2.GLUTgl2 which is not there.

demos.xtrans.Main says:
Exception in thread "main" java.lang.RuntimeException: XTDesktopPane requires new Java2D/JOGL support in Java SE 6 and -Dsun.java2d.opengl=true
        at demos.xtrans.XTDesktopPane.<init>(XTDesktopPane.java:109)
        at demos.xtrans.Main.run(Main.java:252)
        at demos.xtrans.Main.main(Main.java:269)

Now on linux_amd64, running the same jar on same computer with run.sh using the same java command,
same launch arguments, throws a core dump. the core dump is at dll loading event of gluegen_rt.so (after normal java dll's)
and gives classdefnotfound for Classloader etc. basic java classes.

right now I dont have the core dump log to paste here simply but just reporting such a thing.

yes I'm using the eclipse jarinjar classloader but it works fine for lwjgl linux_amd64 native in same style jar and other plain jars without native code.

Maybe Sven can confirm, cg was dropped.

The examples using NEWT without AWT are a lot less exposed to the need of opening some packages of modules.

Vecmath isn't a part of the standard Java API despite its old namespace.

I'm under Debian Linux and it works but I can give it a try anew.

Yes CG has been dropped (Cf here for detail : https://forum.jogamp.org/Was-jogl-cg-removed-from-2-4-0-td4042303.html)