RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

mandy chung mandy.chung at oracle.com
Thu Dec 21 21:40:57 UTC 2017



On 12/21/17 9:18 AM, Chris Hegarty wrote:
>> On 21 Dec 2017, at 16:09, mandy chung <mandy.chung at oracle.com> wrote:
>>
>>>> ...
>>> The test is about identifying StackWalker as the replacement
>>> supported API for getCallerClass, which is continues to do.
>>> I could add yet another scenario to test for a different internal
>>> API that also has a replacement, and add the appropriate
>>> @modules to the test to expose its package.
>>>
>> The test shows sun.reflect.Reflection as a removed API seems odd since the class is present but not getCallerClass(int).
> There appears to be some confusion here. My webrev REMOVES
> sun.reflect.Reflection completely, since getCallerClass(int) was its
> last method. For compilation purposes, the test uses a patched
> jdk.unsupported module with sun.reflect.Reflection, but that class
> is not present at runtime. So the sun.reflect.Reflection internal API
> has been removed, no?

That clarifies it.  Thanks.
>
>> p.Main is used to check that reference to sun.reflect.Reflection is flagged as JDK internal use and not a removed class.  I suggest to change it to use another sun.reflect.Reflection API
> There is no other API in sun.reflect.Reflection, unless you mean
> to use something in sun.reflect.ReflectionFactory ?
>

ReflectionFactory or other class in sun.reflect package would do it.
>> and create an issue to follow up sun.reflect.Reflection as flagged as a removed API.
> That’s what the test now does with my changes. Why separate it
> out into a separate issue?   If we need a test for an internal API, I
> can add a scenario that uses sun.reflect.ReflectionFactory.

Yes please. That's what this case intends to verify.

Thanks
Mandy


More information about the core-libs-dev mailing list