RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported

[Chris Hegarty]

Mandy,

The webrev has been updated in-place
  http://cr.openjdk.java.net/~chegar/8137058/
  http://cr.openjdk.java.net/~chegar/8137058/jdk_incremental.diffs

All 'core', 'pit', and 'hotspot' testsets have been successfully run on
Mac, Linux, Windows, and Solaris.

On 13 Apr 2016, at 18:43, Mandy Chung <mandy.chung at oracle.com> wrote:

>>> This patch will likely impact existing libraries that filter out reflection frames (IIRC Groovy and log4j may be examples) doing Class::getName().startsWith(“sun.reflect”).  It may worth call out this incompatibility in JEP 260.

I added the following note to the Risks and Assumptions section of JEP 260:

Beyond the proposed critical APIs for `sun.reflect`, said package contains
the machinery that implements the `java.lang(.reflect)` subsystem. That
machinery will be moved to an internal, non-exported, package in the base
module. Consequently, the stack trace of reflective calls will appear
somewhat different. That is, stack frames that represent the reflective
implementation will see their class name ( `StackTraceElement.getClassName()` )
change from `sun.reflect.XXX` to `jdk.internal.reflect.XXX`. Any code
analysing, or filtering, based on the stack trace element's class name
should be updated appropriately, to handle this. See
[8137058](https://bugs.openjdk.java.net/browse/JDK-8137058) for further
details.

-Chris.