Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)
On 10/08/2013 06:04 AM, Mandy Chung wrote: On 10/7/2013 9:45 PM, David Holmes wrote: Hi Mandy, Note that unless you push both hotspot and jdk changes through the same forest you will need separate bugs for each part. You will also need a HSX committer to do the hotspot push. I do plan to push them separately meaning that the jdk change will wait until the hotspot change is integrated. I think the hotspot integration is weekly. I am not a HSX committer :( Since I have your attention, can you sponsor my hotspot change? For such small hotspot changes it seems overly restrictive to have to push then through a hotspot integration forest. We have a perfectly good hotspot repo in tl, why not use it? -Chris. Mandy David On 7/10/2013 6:24 PM, Mandy Chung wrote: JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ It remains to be an unsupported API and JDK should not use this method and it's not annotated with @CallerSensitive. I considered detecting if this method is called by a system class (loaded by null loader) and throw an error. I decided to minimize the compatibility risk in case if there is any existing code added to the bootclasspath depending on this private API. Thanks Mandy
Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)
On 8/10/2013 7:18 PM, Chris Hegarty wrote: On 10/08/2013 06:04 AM, Mandy Chung wrote: On 10/7/2013 9:45 PM, David Holmes wrote: Hi Mandy, Note that unless you push both hotspot and jdk changes through the same forest you will need separate bugs for each part. You will also need a HSX committer to do the hotspot push. I do plan to push them separately meaning that the jdk change will wait until the hotspot change is integrated. I think the hotspot integration is weekly. I am not a HSX committer :( Since I have your attention, can you sponsor my hotspot change? For such small hotspot changes it seems overly restrictive to have to push then through a hotspot integration forest. We have a perfectly good hotspot repo in tl, why not use it? Even if tl forest was used it still has to be pushed by a hsx committer and via JPRT. Until we have some definitive processes in place (current ones are ad-hoc) pushing the hotspot changes first is a simple but un-timely approach. Otherwise additional coordination is needed regardless of whether you use hsx forest or tl forest to push from. David - -Chris. Mandy David On 7/10/2013 6:24 PM, Mandy Chung wrote: JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ It remains to be an unsupported API and JDK should not use this method and it's not annotated with @CallerSensitive. I considered detecting if this method is called by a system class (loaded by null loader) and throw an error. I decided to minimize the compatibility risk in case if there is any existing code added to the bootclasspath depending on this private API. Thanks Mandy
Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)
JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ It remains to be an unsupported API and JDK should not use this method and it's not annotated with @CallerSensitive. I considered detecting if this method is called by a system class (loaded by null loader) and throw an error. I decided to minimize the compatibility risk in case if there is any existing code added to the bootclasspath depending on this private API. Thanks Mandy
Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)
On 10/07/2013 10:24 AM, Mandy Chung wrote: JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ It remains to be an unsupported API and JDK should not use this method and it's not annotated with @CallerSensitive. I considered detecting if this method is called by a system class (loaded by null loader) and throw an error. I decided to minimize the compatibility risk in case if there is any existing code added to the bootclasspath depending on this private API. Thanks Mandy The Java side is Ok for me. cheers, Rémi
Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)
On 07/10/2013 09:24, Mandy Chung wrote: JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ It remains to be an unsupported API and JDK should not use this method and it's not annotated with @CallerSensitive. I considered detecting if this method is called by a system class (loaded by null loader) and throw an error. I decided to minimize the compatibility risk in case if there is any existing code added to the bootclasspath depending on this private API. I liked the direction this was going with the walkStack and firstCaller proposal but it is way too late in jdk8 to have any time to get feedback. So I agree that temporarily restoring the unsupported Reflection.getCallerClass(int) is the right thing for now. As the standard API is likely to be significant then it probably warrants a JEP. As regards the webrev then the changes looks okay. I guess you could rename one of the native methods to avoid the non-obvious name mangling but since it is only temporary then I could live with what you have. -Alan
Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)
On 10/7/2013 11:34 AM, Christian Thalinger wrote: Unfortunate but I understand. It might be a good idea to add a getCallerClass(-1) call to the test case. The VM should throw an exception if JVM_GetCallerClass is called by any method other than Reflection.getCallerClass(). It's a good idea to add such test case. thanks Mandy On Oct 7, 2013, at 1:24 AM, Mandy Chung mandy.ch...@oracle.com wrote: JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ It remains to be an unsupported API and JDK should not use this method and it's not annotated with @CallerSensitive. I considered detecting if this method is called by a system class (loaded by null loader) and throw an error. I decided to minimize the compatibility risk in case if there is any existing code added to the bootclasspath depending on this private API. Thanks Mandy
Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)
Hi Mandy, Note that unless you push both hotspot and jdk changes through the same forest you will need separate bugs for each part. You will also need a HSX committer to do the hotspot push. David On 7/10/2013 6:24 PM, Mandy Chung wrote: JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ It remains to be an unsupported API and JDK should not use this method and it's not annotated with @CallerSensitive. I considered detecting if this method is called by a system class (loaded by null loader) and throw an error. I decided to minimize the compatibility risk in case if there is any existing code added to the bootclasspath depending on this private API. Thanks Mandy
Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)
On 10/7/2013 9:45 PM, David Holmes wrote: Hi Mandy, Note that unless you push both hotspot and jdk changes through the same forest you will need separate bugs for each part. You will also need a HSX committer to do the hotspot push. I do plan to push them separately meaning that the jdk change will wait until the hotspot change is integrated. I think the hotspot integration is weekly. I am not a HSX committer :( Since I have your attention, can you sponsor my hotspot change? Mandy David On 7/10/2013 6:24 PM, Mandy Chung wrote: JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ It remains to be an unsupported API and JDK should not use this method and it's not annotated with @CallerSensitive. I considered detecting if this method is called by a system class (loaded by null loader) and throw an error. I decided to minimize the compatibility risk in case if there is any existing code added to the bootclasspath depending on this private API. Thanks Mandy
