> On Apr 14, 2016, at 10:38 AM, Chris Hegarty <chris.hega...@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.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. Thanks for this. Mandy
