Unable to determine GraphicsConfiguration

possible solution (from another java library with native libraries, namely lwjgl for reference):
add also the native jars into eclipse user library list, not only the non-native libraries.

in all cases, the fat runnable jar file with the correct libraries on the zip root did not run by double clicking or from the console.
which I assume will also be solved when the native libraries are added to the class path library list, not only the non-native library list.

I assume wrong:

Exception in thread "main" com.jogamp.opengl.GLException: Unable to determine GraphicsConfiguration: WindowsWGLGraphicsConfiguration[DefaultGraphicsScreen[WindowsGraphicsDevice[type .windows, connection decon, unitID 0, handle 0x0, owner false, NullToolkitLock[obj 0x633a009d]], idx 0], pfdID 9, ARB-Choosen true,
        requested GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw], on-scr[.]],
        chosen    GLCaps[wgl vid 9 arb: rgba 8/8/8/0, opaque, accum-rgba 16/16/16/16, dp/st/ms 24/0/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw], on-scr[.]]]

Command line:

C:\Program Files\Java\jdk-21\bin\javaw.exe "-Djava.library.path=C:\eclipse\pkg\jogl-v2.5.0-bin;C:\eclipse\pkg\jogl-v2.5.0-bin"
-Dfile.encoding=UTF-8
-Dstdout.encoding=UTF-8
-Dstderr.encoding=UTF-8
-p "C:\eclipse\pkg\jogl-v2.5.0-bin\gluegen-rt.jar;C:\eclipse\pkg\jogl-v2.5.0-bin\jogl-all.jar;C:\eclipse\pkg\jogl-v2.5.0-bin\gluegen-rt-natives-windows-amd64.jar;C:\eclipse\pkg\jogl-v2.5.0-bin\jogl-all-natives-windows-amd64.jar"
-classpath "C:\stuff\data\projects\joglrenderengine\bin"
-XX:+ShowCodeDetailsInExceptionMessages
--add-modules ALL-MODULE-PATH fi.jkauppa.joglrenderengine.JOGLRenderEngine

Adding these did not help: --add-exports java.base/java.lang=ALL-UNNAMED --add-exports java.desktop/sun.awt=ALL-UNNAMED --add-exports java.desktop/sun.java2d=ALL-UNNAMED

Final tried command line from eclipse:

C:\Program Files\Java\jdk-21\bin\javaw.exe
--add-exports java.base/java.lang=ALL-UNNAMED
--add-exports java.desktop/sun.awt=ALL-UNNAMED
--add-exports java.desktop/sun.java2d=ALL-UNNAMED "-Djava.library.path=C:\eclipse\pkg\jogl-v2.5.0-bin;C:\eclipse\pkg\jogl-v2.5.0-bin"
-Dfile.encoding=UTF-8
-Dstdout.encoding=UTF-8
-Dstderr.encoding=UTF-8
-p "C:\eclipse\pkg\jogl-v2.5.0-bin\gluegen-rt.jar;C:\eclipse\pkg\jogl-v2.5.0-bin\jogl-all.jar;C:\eclipse\pkg\jogl-v2.5.0-bin\gluegen-rt-natives-windows-amd64.jar;C:\eclipse\pkg\jogl-v2.5.0-bin\jogl-all-natives-windows-amd64.jar"
-classpath "C:\stuff\data\projects\joglrenderengine\bin"
-XX:+ShowCodeDetailsInExceptionMessages
--add-modules ALL-MODULE-PATH fi.jkauppa.joglrenderengine.JOGLRenderEngine

I see that the libraries are under -p and not under "-Djava.library.path=" tho. those were generated to command line in eclipse for lwjgl and work, and the fat runnable jar zip file works too.

No difference for the eclipse packaged runnable .jar file. Same error.

Contents of the MANIFEST.MF file (libraries/natives at the root of the jar zip file):

Manifest-Version: 1.0
Main-Class: org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader
Rsrc-Class-Path: ./ gluegen-rt.jar jogl-all.jar gluegen-rt-natives-windows-amd64.jar jogl-all-natives-windows-amd64.jar
Rsrc-Main-Class: fi.jkauppa.joglrenderengine.JOGLRenderEngine
Class-Path: .

Why not using jogamp-fat.jar instead?

I'll check it out. hopefully it solves all these issues in one.

Nope still this error even if its only one .jar to put in the user library with its source .jar:

Exception in thread "main" com.jogamp.opengl.GLException: Unable to determine GraphicsConfiguration: WindowsWGLGraphicsConfiguration[DefaultGraphicsScreen[WindowsGraphicsDevice[type .windows, connection decon, unitID 0, handle 0x0, owner false, NullToolkitLock[obj 0x192ecc60]], idx 0], pfdID 9, ARB-Choosen true,
        requested GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw], on-scr[.]],
        chosen    GLCaps[wgl vid 9 arb: rgba 8/8/8/0, opaque, accum-rgba 16/16/16/16, dp/st/ms 24/0/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw], on-scr[.]]]

edit: no effect adding these: --add-exports java.base/java.lang=ALL-UNNAMED --add-exports java.desktop/sun.awt=ALL-UNNAMED --add-exports java.desktop/sun.java2d=ALL-UNNAMED

So far I have not gotten the software running with the jogl library even once, in any form.

Do you use --add-opens to run your program?

no why? no such parameters also for the fat runnable jars as double click started.

the jogl library+native package should not require any commands that are not compatible with runnable jar.
any required console command parameters are extra bad in all cases.

if its so hard to get the library to working, then its the reason itself.
the library should self-load without any arguments. literally.

At first, you're talking about an executable JAR that you run on a double click. We don't patronize our users but this deployment method has some important limitations as either you are restricted to the settings that you can change in the manifest or you have to create a launcher class that undergoes these limitations to run a JRE that has access to all command line parameters.

Secondly, there is no magic, we are not responsible for the changes in Java itself, the modularization brings some useful features but brings its part of complexity. You can't really blame a third party library, we do what we can. On the long term, there is a plan consisting in driving JogAmp more "module friendly" but it requires some efforts in order to avoid breaking things and it's not a trivial task. In the meantime, I tested some of my tutorials under Windows (not at home) and they work, which means that JogAmp isn't broken, there's a way to make it work.

I advise you to look at my tutorial about JOGL and OpenJFX/JavaFX, try to run the example as is, it will give you a working example to start fixing your own stuff. Someone else under Windows succeeded in making it work. By the way, take care of the two way of using --add-opens and --add-exports with the '=' characters, only one syntax is supported in some IDEs and build tools.

Those concerns aren't specific to JogAmp.

i'm not an user of your library in this case. thanks for your co-operation.

if your product or library needs a tutorial, its too complex. ie not a finished usable component.
I advice you to make the component install and using at least the level of lwjgl and/or javafx.

sorry for wasting your time.

You're not wasting my time but as I already wrote several times, the JogAmp community isn't responsible for the changes in Java itself.

I mentioned the arguments you have to use with the "java" command (since Java 9) here:
https://gouessej.wordpress.com/2012/08/01/java-3d-est-de-retour-java-3d-is-back/#commandline
https://gouessej.wordpress.com/2020/04/05/javafx-et-jogl-fonctionnent-ensemble-javafx-and-jogl-work-together/#commandlineinterface

I'm sorry to contradict you but at a certain level of complexity, any library requires a documentation and some tutorials. JogAmp will become easier to use anew when all these "--add-opens" and "--add-exports" clauses become useless. I understand your advice but keeping the backward compatibility with Java < 9 is tricky; if we decided to stop supporting those versions, we could put into JogAmp some module descriptors compatible with Java >= 9 and JogAmp would be a lot less cumbersome to use.

I'll try to run a simple example with JOGL 2.5.0 under Windows 11 Monday or Tuesday, I'll confirm which arguments are necessary.

my design requirements are to be able to run any (native) library directly from a fat jar without modifications or extra trick wrapper run libs.
if this cannot be accomplished with jogl, then I need to use lwjgl and/or javafx, which already do it successfully, or make my own.

the libraries that I mentioned are stand-alone and work without any tutorials or instructions, as it should be.
nothing to contradict, but only the need for manuals and instructions. any such library does not fit my design requirements or to be recommended by me.
performance using any library and product is equal to that with no manuals and instructions if those never existed even if they are written.
more intuitive and self-standing package/product will as ui/ux is better than trying to fix lack of ui/ux simplicity with teaching and manuals.
perfect first time vs. lacking trying to be fixed with lacking fix (I call teaching and manuals as a lacking fix, doubly bad lacking situation).
in other words, if a product needs tutorial explanation, then its too complex, and needs to be made more simple to use.

the only target for me for (native) libraries run time is "recent" meaning oracle jdk-21 as only instruction to install for users. I will not ask users to install any other than "recent" official java version.

one thing that you could do is to release a package version that runs on java jdk-21 as I would like it to do, and have a separate wrapper for java 9 (or whatever you would see to be the best solution) that fulfils both requirements, java-9 and current.
essentially the code base would stay the same for both builds, but the distribution package is separate for target compatibility for minimum maintenance effort to have two output release distribution versions.

so you mean I could manually add the descriptors in the jar files for java 17/21+ for them to run nicely. whichever is the easiest tho.
I would recommend you make the additional distribution package with the descriptors in the jar files. keeps things simple engineer-devs.
Even better would be java17+ descriptors that would simply be ignored by java8- so you can run the library (native) jars both ways, without errors, with java-8 compatible code, but with java-17+ library features.

Actually, I won't make huge comments about other libraries but it's not rare to have to do some extra tricks under some operating systems (-XstartOnFirstThread under OS X or some obscure options to avoid driver conflicts). The first trick is unnecessary with JOGL.

I remind you that the reference implementation of Java has been OpenJDK since Java 7 and the licensing changes that occurred in the meantime should encourage most developers not to use Oracle Java. Moreover, nowadays, you shouldn't rely on a JRE installed on the operating system.

It's up to Sven to decide. Personally, I'd prefer dropping Java 8 support to keep things stupid and simple. Java 22 or 23 will bring another change affecting libraries using JNI, I don't want to drive things more complicated that they need to be. If we have a fully modular branch somewhere, maybe we could build JogAmp with that in the meantime to help you.

Some of your suggestions aren't doable even though they would be very convenient. In my humble opinion, supporting at least 2 LTS Java versions (17, 21) would be enough.

I will push oracle to update the default openjdk 21+ (and others) to run all the native library loading the same way in all operating systems. I mean openjdk21 from oracle as the default (in java-17 and java-21 compatibility modes).

until that, all what I suggested is already working properly for at least in windows jvm if not more in most native layer libraries.

If the libraries would be part of the main java openjdk install by oracle, then all this installing/running/conflicts of native library loading would not be an issue (as the original case would be).
so why would oracle drop support for the libraries including javafx and separate them to non-standard libraries. beats me.

Actually, the native library loading isn't the problem, there are already methods to load them in Java itself but it's impossible to load native libraries directly from JARs probably for security reasons, that's why we have to extract them from JARs before loading them, with the risk that a virus scanner believes we're doing something wrong.

By the way, this is the bug report about supporting Java 11+ features:
https://jogamp.org/bugzilla/show_bug.cgi?id=1404

So I wrote a code that extracts native libs from jar directly into a java provided temporary file folder, and loads the native libraries from there, which works, no warnings or errors.

Here the code for reference:

    public static void loadNativeLibrary(String[] filename, boolean loadresourcefromjar) {
                try {
                        Path tempdir = Files.createTempDirectory("loadlib");
                        String[] temppath = new String[filename.length];
                        for (int i=0;i<filename.length;i++) {
                                if (loadresourcefromjar) {
                                        File libraryfile = new File(filename[i]);
                                        String libraryfilename = libraryfile.getName();
                                        File tempfile = new File(tempdir.toAbsolutePath().toString(),libraryfilename);
                                        BufferedInputStream libraryfilestream = null;
                                        libraryfilestream = new BufferedInputStream(ClassLoader.getSystemClassLoader().getResourceAsStream(libraryfile.getPath().replace(File.separatorChar, '/')));
                                        Files.copy(libraryfilestream, tempfile.toPath(), StandardCopyOption.REPLACE_EXISTING);
                            libraryfilestream.close();
                            temppath[i] = tempfile.toPath().toAbsolutePath().toString();
                                }
                        }
                        for (int i=0;i<filename.length;i++) {
                                System.load(temppath[i]);
                        }
                } catch (Exception ex) {ex.printStackTrace();}
    }

Hello

I've updated the rudimentary example, it works correctly under Microsoft Windows 11 and Java 21, look at the bottom of the page, the --add-opens clauses work as expected:
https://jogamp.org/wiki/index.php?title=Rudimentary_standalone_example_using_the_fixed_pipeline_by_Julien_Gouesse

I will try to add a way of patching existing JARs to drive those options useless when I have some spare time, I don't promise that I will succeed but I'll give it a try for sure.

P.S: I plan to use Apache Ant and maybe Gradle to achieve that. If it works, it will be a temporary solution until another major version is released.

my current failed test command line is (win11 oracle jdk-21):

C:\Program Files\Java\jdk-21\bin\javaw.exe
--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
-Dfile.encoding=UTF-8
-Dstdout.encoding=UTF-8
-Dstderr.encoding=UTF-8
-p "C:\eclipse\pkg\jogamp-fat-v2.5.0\jogamp-fat.jar"
-XX:+ShowCodeDetailsInExceptionMessages
--add-modules ALL-MODULE-PATH fi.jkauppa.joglrenderengine.JOGLRenderEngine

Please can you run the rudimentary example and confirm it works on your machine in order to confirm that a non modular project using JOGL works on it before focusing on your modular project?

Does it still fail when you replace --add-exports by --add-opens?

Why do you need to specify "--add-modules ALL-MODULE-PATH"? As JOGL 2.5.0 isn't modular yet, you cannot use -p (which is a shortcut of --module-path) on it but you can use it on other modules like in my tutorial about OpenJFX/JavaFX.

Where is the module or the JAR containing your own classes?

P.S: If you put both JogAmp and your own classes (your "bin" directory) into the classpath and if you use the same 4 --add-opens clauses than in my example, it will work.

the eclipse project with the rudimentary test program is not modular, without the ALL-MODULE-PATH argument the error will be:

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

I run all my non-modular programs with/without native libraries this way, all others work just fine.

when compiled into the /bin directory its just a normal non-modular java class program.
that I could try to run with the non-modular style run parameters.
I think the modular style run time parameters are default to eclipse run environment even if the project program is not modular.

meh, now it works with this exact run command, pesky -cp dot (run from the /bin directory of the project):
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 -cp "C:\eclipse\pkg\jogamp-fat-v2.5.0\jogamp-fat.jar;." fi.jkauppa.joglrenderengine.JOGLRenderEngine

Sorry but I'm talking about running the rudimentary example outside of Eclipse in order to solve the problems step by step.

Does it work?
C:\Program Files\Java\jdk-21\bin\javaw.exe --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.desktop/sun.java2d=ALL-UNNAMED --add-opens java.desktop/sun.awt=ALL-UNNAMED  --add-opens java.desktop/sun.awt.windows=ALL-UNNAMED -cp "C:\eclipse\pkg\jogamp-fat-v2.5.0\jogamp-fat.jar;C:\stuff\data\projects\joglrenderengine\bin" -Dfile.encoding=UTF-8
-Dstdout.encoding=UTF-8
-Dstderr.encoding=UTF-8
-XX:+ShowCodeDetailsInExceptionMessages
fi.jkauppa.joglrenderengine.JOGLRenderEngine

now it works even without --add-exports using only the --add-opens arguments.

I moved the jogamp-fat.jar from module includes to classpath in eclipse and now it works.
this should be support both so that the loading method does not matter.

Final working command line running from eclipse is:
C:\Program Files\Java\jdk-21\bin\javaw.exe
--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
-Dfile.encoding=UTF-8
-Dstdout.encoding=UTF-8
-Dstderr.encoding=UTF-8
-classpath "C:\stuff\data\projects\joglrenderengine\bin;C:\eclipse\pkg\jogamp-fat-v2.5.0\jogamp-fat.jar"
-XX:+ShowCodeDetailsInExceptionMessages fi.jkauppa.joglrenderengine.JOGLRenderEngine

You're talking about jogamp-fat.jar. Thank you for your feedback, it's the expected result as JogAmp isn't modular yet.

Actually, my suggestion based on module descriptors won't work because I can open only the packages of the modules I build.