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