Issue #ReflectionWithoutReadability: Proposal

[mark.reinhold at oracle.com]

2016/3/1 9:42 -0800, mark.reinhold at oracle.com:
> Issue summary [1]:
> 
>   Having to add read edges dynamically just to enable reflection is
>   painful, and could slow migration and adoption.  Consider relaxing the
>   access model so that reflection does not require, or perhaps simply
>   assumes, readability.
> 
> Proposal: Adopt the second alternative suggested in the summary.  Revise
> the core reflection APIs (java.lang.reflect) to assume that any module
> that contains code that invokes a reflective operation can read the
> module that defines the types that are the subject of that operation.
> 
> As a consequence, most code that uses reflection will not have to take
> the trouble to add readability edges manually.  Code of this form that
> was previously added to the prototype implementation will be removed.
> 
> This proposal does weaken the fidelity story a tiny bit, in the sense
> that you'll be able to do more at run time than you can in earlier
> phases, but that seems a worthwhile tradeoff in order to ease migration.

Hearing no objections, I'll mark this issue as resolved.

The relevant changes have already been made in the prototype.

- Mark


[1] http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectionWithoutReadability