Suppose you have a non-modularized app with lots of transitive dependencies. Some of them do deep reflection. The first time you try running on a JDK that enforces permissions, it crashes on startup. The first time you run on a JDK that enforces encapsulation, startup fails. You add --add-opens ...=ALL-UNNAMED to make dependency X work. Later, X is upgraded and no longer needs deep reflection. Can you remove the flag? Maybe not: for all you know, Y is also depending on it but only a rarely executed code path. Since they're both in the unnamed module, the flag was keeping both of them happy. So, how do we find out about Y? In Java 16, the answer is easy: First, remove the flag, and then second, enable -illegal-access=debug, and then keep an eye on the prod logs for any stack traces.
In Java 17, that flag is gone. Your choices are: 1. Remove the flag, and hope you don't cause a prod outage, or 2. Modularize your app so you never need to open anything to unnamed module or 3. Try downgrading to Java 16 for a while and run your app that way, or maybe 4. Compile your own JVM which still supports -illegal-access, or simply 5. path of least resistance: keep the -add-opens forever I remember reading somewhere that the intent of removing -illegal access was so that the app owner is forced to get some situational awareness as to which of their dependencies are using deep reflection. As far as I can tell, if the app is not modularized (and I think most still aren't and won't be for quite a while), then this trick only works ONCE. It's almost impossible to KEEP that situational awareness as they upgrade things. Thoughts? ________________________________ The information contained in this message is intended only for the recipient, and may be a confidential attorney-client communication or may otherwise be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please be aware that any dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the message and deleting it from your computer. S&P Global Inc. reserves the right, subject to applicable local law, to monitor, review and process the content of any electronic message or information sent to or from S&P Global Inc. e-mail addresses without informing the sender or recipient of the message. By sending electronic message or information to S&P Global Inc. e-mail addresses you, as the sender, are consenting to S&P Global Inc. processing any of your personal data therein.
