Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)

David Holmes david.holmes at oracle.com
Tue Oct 8 09:35:10 UTC 2013


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



More information about the core-libs-dev mailing list