Posted by RickLutowski on Apr 01, 2023; 11:13pm
URL: https://forum.jogamp.org/Illegal-reflective-access-with-jogamp-java3d1-7-0-final-tp4042358p4042375.html

gouesse,

Placing '--' (double dash) before the 'add-opens' eliminates the "Could not find or load main class" error.  Now it is back to the original 'reflective access' error.  Since '--add-opens' appears to solve the problem, yet does not appear in my OpenJDK11 docs, this option must have been added after JDK11.  The latest LTS is Java17, which would imply that Java17 is the earliest LTS required to run java3d applications, at least on some systems.

This is important info to know.  Unfortunately, it also puts some of us java3d developers in a bit of a quandary.

I recall seeing a post from a developer who wanted to continue using java3d with Java8.  He was advised to upgrade to Java11 (now I guess it might be Java17) not just to get java3d to work, but also other reasons like bug fixes, security fixes, etc.  While these are valid considerations, it is desirable for programs that target a general audience to work on as wide a range of Java installations as possible.  A program that requires a version of the JRE later than the one installed on the potential user's system will likely not get used because most users do not know how to upgrade their JRE, nor can they be expected to take the time and effort to learn. This is why I have taken great care to ensure that CM Creator does not require anything later than Java 8. Similarly, CM Surveyor used to work with Java 1.4 (circa 2004) until I just upgraded it to java3d1.7-final -- and now it suddenly requires Java17!!  Merging CM Surveyor's java3d code into CM Creator to enable hidden line display would then make CM Creator require Java17 instead of just Java8.  It's tough enough to get potential users to try a new program like CM Creator without requiring them to make significant changes to their computer configuration as well!

This entire quandary seems to be rooted in the "illegal reflective access" problem which, based on the posts, goes back at least to java3d1.7-pre.  

Java allows us do some neat things, but that doesn't mean we _should_ do them. Topping this list is sharing data among multiple threads. It is possible to get a performance increase (depending on the hardware) if it's done right, but a debugging and maintenance nightmare results from doing it wrong, and it's easy to do wrong. I would put reflection just under shared data as something to avoid if possible.

How hard would it be to avoid using reflection in java3D?