<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Thanks David, will make a note of it for future reference.<br>
    </p>
    <p>Cheers,</p>
    <p>Peter.<br>
    </p>
    <div class="moz-cite-prefix">On 30/04/2021 12:57 am, David Lloyd
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CANghgrSqTZEGL4m+exQHqahZxHN9D==njcLR93VCSkt9KK4vCg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">
          <div class="gmail_default"
            style="font-family:arial,helvetica,sans-serif">If it helps,
            we've solved this particular problem in a couple of places
            by using an MR-JAR which selects an implementation using
            `StackWalker` when Java 9+ is used.  I will say however that
            it appears to be slightly less performant, which is
            unfortunate (but hopefully fixable at some point in the
            future).</div>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Thu, Apr 29, 2021 at 1:48
            AM Peter Firmstone <<a
              href="mailto:peter.firmstone@zeus.net.au"
              moz-do-not-send="true">peter.firmstone@zeus.net.au</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">We also use the
            SecurityManager for caller sensitive method calls.<br>
            <br>
            I re-implemented a secure implementation of Java
            Serialization, using a <br>
            public API and fewer features (eg no circular links), in
            this <br>
            implementation, each class in an object's hierarchy has its
            own <br>
            namespace, the calling class is discovered using a
            SecurityManager <br>
            subclass.<br>
            <br>
            -- <br>
            Regards,<br>
            <br>
            Peter Firmstone<br>
            0498 286 363<br>
            Zeus Project Services Pty Ltd.<br>
            <br>
            On 29/04/2021 3:37 pm, Peter Firmstone wrote:<br>
            > Which version of Java is this planned for?   Will the
            last version <br>
            > supporting the security manager be a long term support
            version, eg <br>
            > back ports of security patches and TLS technologies?<br>
            ><br>
            > We have our own security manager implementation and
            policy provider <br>
            > implementations.  Both of these are high performance
            and non-blocking <br>
            > and we are able to dynamically grant and revoke some
            permissions.   <br>
            > While I acknowledge the Java policy implementation has
            a significant <br>
            > performance impact, due to blocking permission checks,
            ours is less <br>
            > than 1%.  Our software doesn't share
            PermissionCollection instances <br>
            > among threads, or even have a Permissions cache, <br>
            > PermissionCollection's are generated for each
            permission check and <br>
            > discarded for garbage collection, the Permission object
            themselves are <br>
            > cached (after initialization and safe publication), as
            are the results <br>
            > of repeated permission checks.  We also have our own
            Permission <br>
            > implementations.<br>
            ><br>
            > We have tools that generate policy files with least
            privilege, <br>
            > although we will manually alter them with wildcards,
            for network <br>
            > connections for instance.<br>
            ><br>
            > In our software, dynamic permissions are granted after
            authentication <br>
            > of TLS connections.<br>
            ><br>
            > It is too early for me to tell if there are suitable
            replacement <br>
            > technologies available.  I can understand the
            motivation for reducing <br>
            > Java's software development burden, but I think this
            version of Java <br>
            > might be the last for us, it would certainly be good if
            a long term <br>
            > support version was available, perhaps indefinitely
            lol.<br>
            ><br>
            > Regards,<br>
            ><br>
            > Peter Firmstone<br>
            > Zeus Project Services Pty Ltd.<br>
            ><br>
            ><br>
            > On 16/04/2021 4:05 am, <a
              href="mailto:mark.reinhold@oracle.com" target="_blank"
              moz-do-not-send="true">mark.reinhold@oracle.com</a> wrote:<br>
            >> <a href="https://openjdk.java.net/jeps/411"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://openjdk.java.net/jeps/411</a><br>
            >><br>
            >>    Summary: Deprecate the Security Manager for
            removal in a future<br>
            >>    release. The Security Manager dates from Java
            1.0. It has not been <br>
            >> the<br>
            >>    primary means of securing client-side Java code
            for many years, <br>
            >> and it<br>
            >>    has rarely been used to secure server-side code.
            To move Java <br>
            >> forward,<br>
            >>    we intend to deprecate the Security Manager for
            removal in concert <br>
            >> with<br>
            >>    the legacy Applet API (JEP 398).<br>
            >><br>
            >> - Mark<br>
            ><br>
            <br>
          </blockquote>
        </div>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div dir="ltr" class="gmail_signature">
          <div dir="ltr">- DML • he/him<br>
          </div>
        </div>
      </div>
    </blockquote>
    <pre class="moz-signature" cols="72">
</pre>
  </body>
</html>