-
Notifications
You must be signed in to change notification settings - Fork 460
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Analyze Classes in Java 11 failing with illegal-access=deny and create add-opens parameters #28596
Comments
Use ChatGPT to create an initial list of opens from analyzed classes including the classes it covers. Note these are only classes reached through all runs and testing in the ci build including integration and postman tests it is possible there could be more we are not hitting. --add-opens java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED |
Note to QA: Besides, please export a starter (Settings > Maintenance > Download Starter ZIP File) and use the downloaded file to start up the server again. Check the logs for any serialization/deserialization issue |
Internal QA: Needs work. After some tests we have noticed there are some errors during the 19_Nightly Test _ Run Postman Tests - default
21_Nightly CLI Build _ Build native image on Linux
22_Nightly CLI Build _ Build native image on macOS-Intel
23_Nightly CLI Build _ Build native image on macOS-Silicon
|
Warnings in the CLI should not be part of the scope of this ticket. We have not modified the illegal access paramters for the CLI, any warnings here were there before and only warnings on Java 11. Upgrading Quarkus to 3.5+ to a Java 21 supported version should resolve these issues and should be handled in that issue. |
Taking into account the comment of @spbolton we tagged this card as We have been able to download and upload a starter without catching any error related to an |
Fixed, tested generating a new starter and using that to start a new instance and this is working as expected Tested on trunk [ _75b3f8a ] |
Java 21 is much more strict with changes to the ability to access internal classes and reflection of objects in general. Using reflection any code used to be able to freely change the accessibility of a method so a private method can be externally accessed. This is done with the setAccessible(true) method e.g.
For a while using this has thrown a warning in the logs and the behavior could be altered with --ilegal-access= flag passed when starting up. In java 17 and above this option is removed and deny is the new default which causes errors in any code making use of this.
The ability to add reflective access does still exist but it needs to be explicitly allowed for each module using --add-opens on the command line. Adding this should mostly be thought of as a temporary measure in most cases we should not be attempting to modify the access of internal classes.
The text was updated successfully, but these errors were encountered: