Issue #ReflectionWithoutReadability: Proposal

[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.

- Mark


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