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