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