Issue #ReflectionWithoutReadability: Proposal
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Tue Mar 8 15:59:53 UTC 2016
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
More information about the jpms-spec-experts
mailing list