Discussion: Prefer passing MethodHandles.Lookup over @CallerSensitive
Alan Bateman
Alan.Bateman at oracle.com
Sat Apr 22 10:03:17 UTC 2023
On 21/04/2023 22:37, mandy.chung at oracle.com wrote:
>
> :
>
> On 4/21/23 1:58 PM, Johannes Kuhn wrote:
>>
>> This line works with Java 7 - 16:
>>
>> MethodHandles.publicLookup().findStatic(System.class,
>> "setSecurityManager", MethodType.methodType(void.class,
>> SecurityManager.class));
>>
>> In Java 17 System::setSecurityManager is now @CS - for a good reason
>> - but such a change can break existing code, which should be considered.
>
>
> Yes, this is an unfortunate case that we didn't catch this
> incompatibility. @CS System::setSecurityManager is another category
> which I can't think of a better term yet and so just call it
> "serviceability or reliability" - setSecurityManager uses the caller
> to emit warning with caller information to provide better guidance.
> As more runtime will be implemented in Java than in native, we may see
> more of this.
>
Yes, a small compatibility issue but one that I wouldn't expect many
would run into specific issue, that is, I wouldn't expect to see real
code wanting to set a SM using reflection code and a restricted Lookup
object. I'm curious if you actually ran into this or it is used as an
example? Maybe a framework or tool that is creating a MH for all public
methods and tripping up on @CS methods?
-Alan
More information about the core-libs-dev
mailing list