Post History

TL;DR: **Imperfect > none**

**Re: title.** 

1. Coming thru open door is not a breach. ;-)
2. Encapsulation helps with security because it hides data (prevents exposure). If that data matters, that means less options to have it.

Imperfect defense may dissuade attempts or simply make them harder. Not everyone who's after data will fire up the debugger, will be able to use reflection, etc. Some will. But even so, it's easier to defend a smaller attack surface (JFR events and monitoring). An aside: I believe modules had a counter for reflection (allow/deny options, IIRC).

**JEP language**

Please note you're commenting on something that may well be discussed in front of a committee and/or is being written in a particular way on purpose. Encapsulation should prevent exposure and here's a way to bypass it: why NOT mention it as a security risk? It even sounds better.

It's also overall in-tune with Java language and security approach. Be it Java Coding Guidelines or Java Secure Coding Guidelines, both (IIRC) mention for instance things like integer being negative instead of overflowing. Mention, as in, "this may surprise some devs". Reading similar language in a JEP seems fitting.

Heck, Java 9(again, IIRC), introduced checkIndex in Objects. To check if a code will throw IOOBE. Similar to having a method checking if NPE will be thrown, offered in same class. 

**Sandboxes: OS, Graal, OSGi, Docker, SM, and JVM potential long game**

Sure, OS protection is the way to go. Sure, Security Manager is going away (good). Still, plugins exist (foreign code, same process). Still, notion that app is safer than dependencies will be brought up (secure the deps by treating them as untrusted). Having (later) some level of JVM protection may be good. Graal tries this. I didn't use their sandboxes, note, but docs and mentions are frequent. I also heard OSGi folks say they offer something like it.

OS protection are a form of sandbox. So was SM. It was a path + deep sandbox - high complexity, too high to be easy to use (ergo, often went unused). Dockers, VMs, pods, are simple sandboxes. 

SM WAS done for applets. And when Java APIs were small. And it operated on a deny approach (you have access to java.file so every method now checks if permission's denied) - not so swell now.

For now, for plugins (ran in same process sometimes) we have only stack walker and service loaders and modules (also not perfect defenses, rather incremental steps for something in the future). I wouldn't be surprised if Java fellas came with more, but later. Once they finish removing SM.

**An aside: policy files**
Amazon verifies their policy files for SIMPLE sandbox with advanced math (formal reasoning, look-up Zelkova).

Granting each and every permission to each and every thing in policy files for SM was HARD to do well on Java 6. And API only grew since then. Red Hat did their own tooling to support policy files crafting (can't find it right now, I think they took it off GitHub).

**Bibliography**

1. https://openjdk.org/jeps/401
2. https://snyk.io/blog/securitymanager-removed-java/
3. https://www.oracle.com/java/technologies/javase/seccodeguide.html
4. https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/
5. https://inside.java/2024/12/11/quality-heads-up/
6. https://www.graalvm.org/latest/security-guide/sandboxing/
7. https://www.reddit.com/r/java/comments/15ksmm2/comment/jv7vkn3/
8. https://dockerlabs.collabnix.com/advanced/security/capabilities/
9. https://aws.amazon.com/blogs/security/protect-sensitive-data-in-the-cloud-with-automated-reasoning-zelkova/