Posted by swong on Nov 16, 2018; 5:41am
URL: https://forum.jogamp.org/JOGL-Java-10-modularization-tp4038983p4039286.html

I got the above posted jogl-test code to bring up a blank (black) JOGL canvas on a frame... sort of.   I noticed that it would not run for me when using the provided launch configuration to run the code directly.   The code only ran after it was assembled into its JAR files and the only JAR file that would run was the one that included the dependencies.

The curious thing about the JAR files is that they don't utilize the JAR'd versions of JOGL, i.e. the jogl-all.jar, gluegen-rt.jar and the natives JARs.    Instead, Maven creates an executable JAR (the one with the dependencies) where all the required code is included as un-JAR'd packages.  


Here's a theory to chew on -- I may be way off base but this seems to fit my observations:

One of the reasons that JOGL 2.3.2 doesn't run in a modular project is due to Java treating the multiple JARs in the JOGL system as independent automatic modules and thus does not allow free access of the code in one JAR to the code in another JAR.    I think this may be a particular problem in accessing the native code.

Thus, by putting the entire JOGL system inside of a single JAR file, these access problems go away because module boundaries are not being crossed anymore.  

Possible solutions:
A.  Put the entire JOGL system in a single JAR file.   This could make the JOGL distribution too large for some applications however.   This is the route I am currently pursuing but not successfully yet due to changes in package names and available methods between v.2.3.2 and earlier versions.
Or
B. Make all the JARs in the JOGL system into named modules with internal module-info.java files.   The "requires" and "exports" declarations would have to be figured out for each JAR/module.   This would take a lot of work to accomplish but could greatly reduce the overall JOGL system size for some applications and would not have to rely on the vagaries of automatic modules.   This is arguably the better long-term solution.

Thoughts on this theory, anyone?
 
BTW, does anyone know what the proper replacements for these methods that have disappeared in JOGL 2.3.2?

GLU.destroy()
GLDrawable.getHeight()
GLDrawable.getWidth()

Thank you to all for your help and feedback!