I've been doing some testing with this option for development and testing.
The original implementation with output from --add-opens broke our tests so
quieter is better.
This is really a useful feature. Ideally the goal would be to run with this
option in product build, unit test, and functional testing with no WARNING
messages.
Unlike jdeps which is great for static analysis, this approach also picks up
problems in reflection.
I have encountered problems in javassist, gradle, etc. and entered or updated
bugs for further analysis by the owners.
1. In some cases, it is not possible to eliminate the warning. Assume that you
have a utility that (for whatever reason whether sound or not) makes all
methods on a class accessible by calling setAccessible.
It dutifully catches any exceptions and ignores them. This will show up as a
WARNING when using --permit-illegal-access even though the code will run
successfully.
Assuming my customers may run with this option to look for problems, I want to
change the code to eliminate this warning.
The obvious choice is trySetAccessible but that will also allow access and
produce the warning. Using the expected idiom of
if (ao.canAccess(<null-or-receiver>) || ao.trySetAccessible()) {
doesn't fix it. There is no method to test if setAccessible will succeed. So
the best that we can do, if we can't get rid of the setAccessible, is keep a
list (which looks like it will be small) of known occurrences that are OK.
2. A second issue is related to setting the option. In a complex project,
there are multiple build tools, nested execution of java, etc. Setting it on
the command line is not going to work. The solution is to set it in
_JAVA_OPTIONS (Alan mentioned JDK_JAVA_OPTIONS in an email but I must have
missed that announcement and I'm not quite sure what JDK9/Jigsaw builds it is
in). That works pretty well although it needs special handling if there are
already uses of this variable (they need to be smart enough to append or
prepend) and it needs special handling in cases like doing an exec in ant
without passing down the environment (this variable needs to be explicitly
passed).
It also has the problem that in an automated/distributed environment, you need
to figure out how to get it set initially.
I would find it much easier to be able to set this and other command line
options once in a file under JAVA_HOME.
JDK 9 has set a new precedent of having configuration files under
$JAVA_HOME/conf. It has the simplicity of setting it once for all users of the
JDK. There is a drawback that if you can't share a specific value, then you
need multiple copies of the JDK (e.g., one for conf/security/java.security
crypto.policy=limited and another for crypto.policy=unlimited).
I would like to see an argument file under conf that would be processed before
any explicit argument files passed to java.
-----Original Message-----
From: Mark Reinhold
Sent: Wednesday, March 22, 2017 11:30 PM
To: [email protected]
Subject: Re: Better tools for adjusting to strong encapsulation
Thanks to everyone for all the feedback on this topic.
It appears that issuing warning messages for illegal-access operations enabled
by the precise `--add-opens` and `--add-exports` options is a bit too
aggressive, at least for JDK 9. Perhaps we can enable that in JDK 10 after
there's been more time for libraries, frameworks, and even the JDK itself to
adjust to the realities of strong encapsulation.
For now I suggest that we revert to the previous behavior of these two options,
so that they do not cause warning messages to be issued. The new
`--permit-illegal-access` option will continue to generate warning messages, as
proposed. If those messages are a problem in a particular scenario then they
can be eliminated by switching to an appropriate set of `--add-opens` options,
which can be constructed from the information contained in those messages.
Comments?
- Mark
