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

[Mandy Chung]

> On Apr 14, 2016, at 10:38 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> 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
> 

Looks good.  Thanks for making the change.

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

Thanks for this.
Mandy