WildFly on JDK16+

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

WildFly on JDK16+

Richard Opalka
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: [hidden email]


_______________________________________________
wildfly-dev mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Reply | Threaded
Open this post in threaded view
|

Re: WildFly on JDK16+

Brian Stansberry


On Wed, Apr 7, 2021 at 3:20 AM Richard Opalka <[hidden email]> 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: [hidden email]



--
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 -- [hidden email]
To unsubscribe send an email to [hidden email]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Reply | Threaded
Open this post in threaded view
|

Re: WildFly on JDK16+

Scott Stark
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 <[hidden email]> wrote:


On Wed, Apr 7, 2021 at 3:20 AM Richard Opalka <[hidden email]> 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: [hidden email]



--
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 -- [hidden email]
To unsubscribe send an email to [hidden email]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

_______________________________________________
wildfly-dev mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Reply | Threaded
Open this post in threaded view
|

Re: WildFly on JDK16+

Richard Opalka
Hello Scott,

   We do not have that list yet.

Rio

On Thu, Apr 8, 2021 at 3:46 PM Scott Stark <[hidden email]> wrote:
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 <[hidden email]> wrote:


On Wed, Apr 7, 2021 at 3:20 AM Richard Opalka <[hidden email]> 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: [hidden email]



--
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 -- [hidden email]
To unsubscribe send an email to [hidden email]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


--
Richard Opalka
Principal Software Engineer
Red Hat JBoss Middleware
Mobile: +420 731 186 942
E-mail: [hidden email]


_______________________________________________
wildfly-dev mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s