<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <p><br>

    </p>

    <br>

    <div class="moz-cite-prefix">On 1/23/17 8:16 PM, Cantor, Scott

      wrote:<br>

    </div>

    <blockquote cite="mid:489EA3FE-4E82-4A98-AE14-FE6D21A0D68B@osu.edu"

      type="cite">

      <pre wrap="">

</pre>

      <pre wrap="">

That's bizarrely complicated the way they piecemeal all of it. Don't see why they don't just lay out a file of properties and chain it to the system properties, same as Spring.

</pre>

    </blockquote>

    <br>

    My hazy recollection is that it's all about limiting who/what can

    access and change things when you are running under a security

    manager, since the java.security props configure and influence the

    security manager behavior itself (like policy, etc).  So they

    maintain a segregation between system props and the security props

    so that they aren't all in the same bucket, and the perms are

    distinct. You may want to give a program the ability to read and/or

    modify system props, but that shouldn't inherently include

    influencing the very behavior of the security manager itself.<br>

    <br>

    If/when you're not running under a security manager, there may or

    may not be any practical benefit to the segregation, so the reason

    for it is less obvious I guess.<br>

    <br>

  </body>

</html>