10:20 a.m.
Hello Brian, Scott and others,
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).
[1] http://openjdk.java.net/projects/jdk/16/
[2] https://openjdk.java.net/jeps/396
[3] https://cr.openjdk.java.net/~mr/jigsaw/jdk8-packages-denied-by-default
--
Richard Opalka
Principal Software Engineer
Red Hat JBoss Middleware
Mobile: +420 731 186 942
E-mail: ropalka(a)redhat.com