Security Manager is one of the only unique selling points of Java, to remove it (without removing it because you need it underneath) is as big of a blunder as removing Applets from browsers and replacing it with something worse: WASM without GC and then adding GC to WASM...
If SVTwP is not better than NIO; Java ends with JDK 23.
> Warnings issued in JDK 17–23 generated minimal discussion in the Java ecosystem
Because no feature added after 1.8 made sense, so nobody upgraded. They are taking decisions off the wrong data.
> they are encouraged to transition to alternative sandboxing and API interception mechanisms
Unique, sure. Selling point? I really don't think so. This idea of "safely" running untrusted code in the jvm sandbox both never materialized (constant stream of sandbox-escape vulns i've seen over the years) and also was at the wrong level - anyone doing multi-tenant code execution is doing it via things like gvisor or at the OS-level.
I don't think I buy your assertion that nobody has upgraded. I know of a 3000-4000-strong eng org at a certain company that has upgraded all the way from 8 to 17 as of when i left 3 years ago. They primarily wanted the GC improvements because they translated into huge immediate efficiency gains on their workloads (huge Spark/Hadoop spend savings, and moderate savings for the non-big-data jvm workloads).
I do share your lament of applets though. It would've been a way better runtime for portable/install-less/JIT-install things than the current nightmare of html/css/js/etc. But they just didn't have the browser integration - it would've needed to be more than just "look we put a drawing surface into the web browser" - and they didn't have the "window into the world" either (that's browsers). Unfortunately, it's the front door program and platform that owns the users, and that's web browsers.
I grew up hearing about Java vulnerabilities over and over before I really learned programming, so I could not point to any specific ones. But this discussion expresses the same sentiment: https://security.stackexchange.com/questions/57646/why-do-i-...
>The Security Manager was not so hard to maintain it merited a removal without replacement.
It sounds like the OpenJDK folk disagree with you, though. From the JEP:
>The Security Manager has not been the primary means of securing client-side Java code for many years, it has rarely been used to secure server-side code, and it is costly to maintain
>...Improve the maintainability of hundreds of JDK classes that currently delegate resource-access decisions to the Security Manager.
>The OpenJDK Core Libraries Group devotes significant time and energy to reviewing every change to any of these methods. Every new API must be designed, and its implementation carefully audited, with the least-privilege model in mind. However, only a tiny number of applications actually enable the Security Manager.
This seems like a big win in terms of maintainability of the core libraries.
The Security Manager was dead as soon as applets ceased to be relevant (which happened a long time before WASM appeared btw.). Deploying the Security Manager requires designing the application up front for it as well as maintaining policy files. Most developers are not aware how to do either.
But its biggest weakness is that it has to restrict a lot of overly powerful APIs. That's like spooning water with a sieve. It would have been better to let the host application restrict which APIs are visible in the first place, like it is done with browser APIs.
The projects that didn't upgrade so far are either dusty business-crirical applications that nobody cares to touch or that utterly deprioritize upgrades unless circumstances force them to. Most of the new features make a lot of sense, but nobody is going to gamble their job on forcing an upgrade just to being able to use them.
To suppress things like `System.exit(0)`, agents can be used. Proper sandboxing solutions would be VMs and containerization technologies. Achieving perfect sandboxing within a process is hopeless anyway.
With some work on better tooling it could've been used to detect and thwart supply chain attacks, which are a growing concern. Process level sandboxing is too coarse.
If SVTwP is not better than NIO; Java ends with JDK 23.
> Warnings issued in JDK 17–23 generated minimal discussion in the Java ecosystem
Because no feature added after 1.8 made sense, so nobody upgraded. They are taking decisions off the wrong data.
> they are encouraged to transition to alternative sandboxing and API interception mechanisms
Feel free to link to anything useful!