1. 19
  1.  

  2. 10

    The Java SecurityManager’s design was always rather odd.

    Rather than follow the natural object-capability security in the initial version of the Java applet sandbox, they added an ACL-based mechanism which associated authority with the running code (conceptually like the setuid bit in Unix) by inspecting the active method calls on the stack. It’s no surprise that this was slow and hard to program.

    I’m just not sure why they chose to take this approach, and I’ve never been able to figure it out from my research…

    1. 9

      When was the last time a major programming language removed a major feature? Nice to see they have a long term plan for the deprecation process.

      1. 3

        Agreed, too few programming languages have mature policies around this.

        (Rust is probably a good example of a new-ish language going down the non-sustainable route of “we are not going to remove anything ever”.)

        1. 1

          Isn’t the purpose of Rust Editions to allow making backwards incompatible changes like removing/fixing functions and features?

          1. 1

            No:

            Editions can contain incompatible changes, such as including a new keyword that conflicts with identifiers in code. However, unless you opt in to those changes, your code will continue to compile even as you upgrade the Rust compiler version you use.

            All Rust compiler versions support any edition that existed prior to that compiler’s release, and they can link crates of any supported editions together. Edition changes only affect the way the compiler initially parses code.

          2. 1

            Java itself still ships APIs that were deprecated 20 years ago, mainly because there’s no replacement for it. Thread.kill might be unsafe but there’s no alternative.

            As a long time Rubyist, there’s a number of features which do not provide the enough bang for the buck and I’d like to see removed. Matz has been willing to remove unpopular features, eg $SAFE, so we’ll see what the future holds.

            1. 1

              Java removed Thread.destroy() and Thread.stop(Throwable) in Java 11, only Thread.stop() is still only deprecated.

              It also deprecated some of the most basic constructors for removal in Java 17 (i. e. new Integer(...), new Double(...) etc.).

              Say what you want about Java, but they are regularly, but not lightly, removing things from it.

              1. 1

                Thanks, I meant Thread.stop. Glad to hear they are cleaning things up a little more aggressively now.

        2. 3

          Hmm, I wonder how things like JEXL Sandbox will work now that the SM is going away?