Proposal: Allow illegal reflective access by default in JDK 9

[Alan Bateman]

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