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
A related con is it is not conceptually possible to identify all such cases, as WildFly is an extensible server and we don't know what extensions outside the WF code base do. Deployments too.
A possible solution to this is to ensure we have the necessary hooks to allow users to append to, or perhaps completely override, the opens we declare. This would need to cover all the relevant cases,, i.e. all our launch scripts, domain mode configuration, bootable jar, launcher lib in WildFly Core...
If the opens we identify for our own code cover the likely modules, there may not be much need for people to use this.
In my opinion we should go B) way and open only what is necessary. What do you think guys?
This sounds like the right approach beyond the very short term[1]. If for some reason B) is blocking us from doing delivering something we can fall back to A.
[1] Very short term, meaning quick tactical workarounds, e.g. we want to see what the EE 9.1 TCK looks like for WildFly Preview when we run it with JDK 16 and we want to get past these kinds of problems so we can see other things. But that kind of workaround could hopefull be done without changing the WildFly code itself.
This also opens the question whether all WildFly subprojects shouldn't be tested with JDK16+?
I think that needs to start happening, yes. In the release announcements for final releases I include language like this:
"Our recommendation is that you run WildFly on the most recent long-term support JDK release, i.e. on JDK 11 for WildFly 23. While we do do some testing of WildFly on JDK 12 and 13, we do considerably more testing of WildFly itself on the LTS JDKs, and we make no attempt to ensure the projects producing the various libraries we integrate are testing their libraries on anything other than JDK 8 or 11."
JDK 17 will be LTS so once we provide support for it, it would be good if it could be without the caveats I use there for JDK 12 / 13.