Module.addOpens should log if the package has been opened for illegal access for the caller
Johannes Kuhn
info at j-kuhn.de
Thu Dec 10 10:32:27 UTC 2020
On 10-Dec-20 8:59, Alan Bateman wrote:
> On 09/12/2020 22:45, Johannes Kuhn wrote:
>> Hope I got the right mailing list, otherwise please direct me there.
>>
>> Module.addOpens currently doesn't produce an illegal access warning
>> if the target package has only be opened for illegal access.
>>
> The Module methods were not intended to emit warnings. The warnings
> are supposed to be emitted by calls to AccessibleObject methods that
> will fail when the default switches to deny illegal reflective access
> by default.
An argument could be made that MethodHandles.privateLookupIn also emits
a warning - so an other piece of code that treats "open" vs "open for
illegal access" differently.
Module.addOpens is a 3rd place where it matters that the package is open
and that doesn't emit warnings.
The other uses of Module.isOpen are related to resources, which I didn't
look into yet.
So: Why do all reflective operations (except reflective open) emit a
warning if the package has only been opened for illegal access?
>
> I think your argument is that if any of the standard or JDK modules
> opens a package for illegal reflective access then code on the class
> path can use Module.addOpens to open the package, which has the
> effective of suppressing warnings. That behavior is there to support
> the --add-opens command line option.
Using --add-opens to suppress the warning is not really the big point -
if you don't get any warning, then running with --illegal-access=deny
should not break the program.
Or, to put in in an other way: With --add-opens you don't rely on
illegal access anymore.
>
> So I think this needs a bit of thinking time to see if it's worth
> trying to do anything here. The default has switched for Java 16 and
> the intention is that the --illegal-access option will be removed by a
> future JEP. I agree it would be sad to see hacks like this in
> production, it would be far better to channel the energy being put
> into hacking around warnings to fixing fragile code to not rely on JDK
> internals.
>
> -Alan
In short, there are 3 reflective areas where Module.isOpen matters:
AccessibleObject, MethodHandles.privateLookupIn and Module.addOpens.
Module.addOpens doesn't emit a warning, the others do.
If a module has been reflectively opened, then no warning should
emitted, right.
But reflectively opening a package should emit such a warning if you can
only do that because it has been opened to you for illegal access.
As an other note, I think we already did enter warning fatigue - "yeah,
there will be a warning, doesn't matter", "just accept the cookies"...
So the change to have a default of --illegal-access=deny is a good
thing. Hopefully the result is not "just run it with
--illegal-access=permit".
And yeah, I'm a bit late to the party.
- Johannes
More information about the jigsaw-dev
mailing list