<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 4/21/23 1:58 PM, Johannes Kuhn
wrote:<br>
</div>
<blockquote type="cite" cite="mid:ae9106bc-7dce-9300-65cb-ce2de4ecb0dc@j-kuhn.de">
<blockquote type="cite" style="color: #007cff;">
<blockquote type="cite" style="color: #007cff;">5. Making
existing methods @CallerSensitive can lead to small backwards
compatibility issues - as the public lookup can't lookup those
methods anymore.
<br>
<br>
</blockquote>
Can you explain what you observe about this? Public lookup has
access to public members of public classes in packages that are
exported unconditionally. @CS should have no impact to public
lookup.
<br>
<br>
<br>
</blockquote>
<br>
This line works with Java 7 - 16:
<br>
<br>
MethodHandles.publicLookup().findStatic(System.class,
"setSecurityManager", MethodType.methodType(void.class,
SecurityManager.class));
<br>
<br>
In Java 17 System::setSecurityManager is now @CS - for a good
reason - but such a change can break existing code, which should
be considered.
</blockquote>
<p><br>
</p>
<p>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.<br>
</p>
<p>Mandy<br>
</p>
</body>
</html>