Better tools for adjusting to strong encapsulation

[Stephen Felts]

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: jigsaw-dev at openjdk.java.net
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