Hi!
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:
http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509
Web:
http://codefx.org
a blog about software development
https://www.sitepoint.com/java
high-quality Java/JVM content
http://do-foss.de
Free and Open Source Software for the City of Dortmund
Twitter:
https://twitter.com/nipafx
