According to [1] JEP 396 [2] JDK 16 changed default mode of global config option '--illegal-access' from mode 'permit' to mode 'deny'. This means that code on the class path cannot use reflection to access the non-public elements of java.* packages, and all elements of sun.* and other internal packages, for packages that existed in JDK 8 - see complete list [3]. The 'permit', 'warn', and 'debug' modes of the '--illegal-access' option are still supported and they work. These modes still allow us to choose relaxed strong encapsulation. The problem is it is expected a future JEP will remove the '--illegal-access' option entirely. When this will happen it will not be possible to open all of the JDK 8 packages via a single command-line option. It will still be possible to use the '--add-opens' command-line option to open specific packages. As preparation for the removal of the '--illegal-access' option this option was deprecated for removal as part of JEP 396 effort [2]. As a consequence, specifying that option to the java launcher causes a deprecation warning being issued.
There are two possibilities how to address JDK 16+ regressions: A) Use '--illegal-access=permit' - Pros: * No need to collect all required '--add-opens' for every jar - Cons: * Will issue warning about 'being deprecated option' on the commandline * It is very dangerous because such default opens all JDK (not just some) internal packages to all code on the classpath * When '--illegal-access' will be removed we will need to go B) either way B) Use only '--add-opens' options to open only identified packages - Pros: * No warning about deprecated '--illegal-access' option will be issued * It is more secure - only required JDK packages will be open for reflection for code on the classpath * No problem will pop up when '--illegal-access' option will be eliminated from future JDK * Documenting all necessary '--add-opens' will give us better insight to potentially dangerous code in some libraries - Cons: * Some (but meaningful) effort is needed to collect and identify all needed '--add-opens' clauses
In my opinion we should go B) way and open only what is necessary. What do you think guys? This also opens the question whether all WildFly subprojects shouldn't be tested with JDK16+?
Rio
PS: All that has been said above doesn't apply to the 'sun.misc' package. This package still is and will always be exported by the 'jdk.unsupported' module and thus it is and will always be accessible from classpath code (including reflection access).