[wildfly-dev] Re: WildFly on JDK16+

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