Hi Alan,
On 05/19/2017 01:05 PM, Alan Bateman wrote:
On 19/05/2017 10:48, 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.
You are correct. If the package is opened at run-time:
1. All public members of public types in the package are accessible.
This includes both static and reflective access.
2. All members of all types in the package can be reflected on when
using setAccessible or privateLookupIn.
The reason you don't get warnings with the static references is
because access checking in the VM is very low level and we
deliberately decided to avoid the invasive changes needs to report
warnings here. The latest proposal does not change this, it's just too
late in JDK 9 to take on this surgery.
-Alan
Ok, I can understand that such interpretation of "opens" is necessary
for JDK 8 compatibility story. If something is "open" then it behaves
exactly like in JDK 8 or before (apart from compilation) regardless of
packages being exported or not. But from consistency perspective,
explicit "exports" should be required just like "public" modifiers are
required to access members without .setAccessible(true) or without
.privateLookupIn().
This would not hinder the ability for frameworks to access members. It
would just require them to call .setAccessible(true)/.privateLookupIn()
in more places, but would be safer too as "suppressAccessChecks"
permission would be required for non-exported package access like it is
required for "private" members.
I'm sorry I haven't noticed this before. It is probably to late to
change this now. Was this deliberate choice (to promote compatibility
with existing code)?
Regards, Peter
