Proposal: Allow illegal reflective access by default in JDK 9
Stephen Felts
stephen.felts at oracle.com
Fri May 19 13:38:27 UTC 2017
Here's something to think about with respect to noise by whatever choice is made for the default for --illegal-access.
I've run a lot of code using the current --permit-illegal-access.
One of the problems with this option is that there can be errors detected for code that is working correctly and/or has already been fixed for JDK9.
Since I have been working on identifying and entering bugs for JDK9 problems, I have also been collecting a list of warnings for code that is valid so I can ignore them.
Here are a few public ones.
org.python.core.PyJavaClass - Jython
com.sun.xml.bind.v2.runtime.reflect.opt.Injector – standalone jaxb
com.sun.xml.ws.model.Injector – standalone jaxws
net.sf.cglib.core.ReflectUtils$ - cglib
Summarizing the use cases:
1. The code calls setAccessible and correctly catches and ignores the exception for those that fail. It would be a big change to make this call setAccessible lazily.
2. The code continues to use the JDK8 approach and if that fails it falls back to an approach that works on JDK9 and/or other non-Hotspot platforms. In some cases, this code has been around for a decade or more (e.g., to handle platforms without Unsafe).
In work flows that I have seen, a message would always be printed for every process, even though there is no real problem. That’s not acceptable in a production environment.
Let's assume that there is at least one illegal access per process that is run.
The current proposal will print one message per process. That can be a lot of noise. Examples:
- Running tests with fork for every test (obviously not a production environment).
- If you are doing internal process generation that used to be invisible to your customers, it's now visible.
More information about the jigsaw-dev
mailing list