On 19/05/2017 13:02, Peter Levart wrote:
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)?
`opens` is intended to open a package for reflective access. Code can
use the reflection APIs to get at public members of public types in the
package, it shouldn't need setAccessible to do that.
The static reference case that Volker brought up is somewhat of a corner
case in this discussion. Readability aside, it would be inconsistent if
reflection APIs could access public members of public types in the
package but bytecode could not. The other corner case is code generation
at run-time which also should also work (assuming both visibility and
readability).
-Alan
