RFR  8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported
mandy.chung at oracle.com
Thu Apr 14 17:55:54 UTC 2016
> On Apr 14, 2016, at 10:38 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> The webrev has been updated in-place
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
> (https://bugs.openjdk.java.net/browse/JDK-8137058) for further
Thanks for this.
More information about the core-libs-dev