Post History

Let's pretend [Java was a capability-safe language](https://en.wikipedia.org/wiki/Joe-E).

Now let's consider the IDE scenario and imagine that we want to support Copilot-like AI plugins that use a 3rd-party service. To access these services, the plugins will need an API key.

This is easy to accomplish. The plugin interface simply allows the untrusted plugins to request to be given an `ApiRequester` object which they can use to make requests to the AI services. If the API key was stored in a private field of the `ApiRequester` object, then simple encapsulation would stop the untrusted code from being able to get at it.

If, for some bizarre reason, `ApiRequester` was a value object per this JEP, then the untrusted code could attempt to guess the API key. The most efficient way would likely to be via `hashCode`. Either way, the key point is that attempts would not require actually making requests which could be detected and throttled or lead to a lock out^[As an example of attenuation possible in this model, one malicious thing the untrusted plugin could do is make a bunch of spurious requests to waste our money. Again, this is easily solved by simply having `ApiRequester` incorporate some throttling logic of its own.].

None of the above scenario requires `SecurityManager` or sandboxing or even full object capability discipline. It only requires that the untrusted code doesn't have access to encapsulation-breaking capabilities. In a capability-safe language, this property would be easy to verify. Simply don't give such capabilities to the untrusted plugins. Even in actual Java, I don't believe it would be hard to check the bytecode of an untrusted plugin and ensure it only uses a whitelisted set of imports and methods. So, you would disallow reflection methods and access to much or all of `java.io` / `java.nio`, for example. This does not stop the plugins from being able to make network requests, say; it just means they can only do it via objects the trusted code provides, e.g. the `ApiRequester` above.

While operating at the source level, Joe-E (linked above) shows how we could limit Java to guarantee capability safety. Other than the elimination of ambient authority, these limitation would not effect much Java code. It would certainly leave the experience of writing Java largely the same. Even something like reflection could be provided in a capability-safe manner by simply making [mirrors](https://bracha.org/mirrors.pdf) only accessible via a capability (which may itself be attenuated to, for example, disallow reflecting on any trusted code).

The `SecurityManager` was an unnecessary, complicated, and only somewhat effective approach security. It going away is probably a good thing for Java security.