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?

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

Do we have a list of the contexts where these illegal access warnings are happening? On Wed, Apr 7, 2021 at 10:29 AM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > On Wed, Apr 7, 2021 at 3:20 AM Richard Opalka <ropalka(a)redhat.com&gt; wrote: > >> 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. > > >> 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 >> >> > > -- > Brian Stansberry > Senior Principal Software Engineer and Manager > Principal Architect, Red Hat JBoss EAP > He/Him/His > If I am writing outside of normal office hours, it is my choice; you do > not need to do the same > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s