Proposal: Allow illegal reflective access by default in JDK 9

Nicolai Parlog nipa at
Fri May 19 10:41:59 UTC 2017


I'm too lazy to try right now but I'm pretty sure I repeatedly observed
the behavior Volker describes:

A module depends on an internal type and is compiled successfully
thanks to --add-exports. At run time it would fail without flags and
would work with --add-exports but it also works with --add-opens.

 so long ... Nicolai

On 19.05.2017 12:24, Peter Levart wrote:
> Hi Volker,
> On 05/19/2017 11:48 AM, Volker Simonis wrote:
>> From my understanding, at run-time, "open" implicates "exports"
>> (i.e. if a module M1 opens a package P for some other module M2
>> it also, implicitly exports P to M2). The  "big kill switch" in
>> both, its old and in the newly proposed form, usually only refers
>> to "enabling reflective access" but doesn't explicitly mentions
>> that it will also, implicitly export the respective packages.
>> Also, the usage of the "kill switch" only produces warnings for
>> reflective accesses which are enabled by the option itself (and
>> not at the same time, explicitly allowed by --add-opens
>> directives). But it doesn't warn about the simple, non-reflective
>> accesses to packages which are implicitly exported by the kill
>> switch as well.
> No, you got it wrong. "opens" is just a backdoor for reflection
> (and MethodHandles.Lookup). It does not implicitly also mean
> "exports". Neither in compile-time nor in run-time. Otherwise
> everything that is declared "public" would be accessible to
> reflection without the need for .setAccessible(true) - therefore
> even to code running with SecurityManager enabled!
> Regards, Peter


PGP Key:

        a blog about software development
        high-quality Java/JVM content
        Free and Open Source Software for the City of Dortmund


More information about the jigsaw-dev mailing list