The is roughly what you are to be able to do with the Java SecurityManager- it was especially intended for code mobility scenarios where you can’t be certain that everything is well-behaved (and not just applets- we used it server side).
But wrangling all those capabilities and policies gets really really difficult on a decent sized system, and comes with a runtime overhead to boot.
Fairly similar at least, yeah. Java has enough power in its reflection APIs, and widely-enough used reflection, that this kind of thing is practically required to be part of the runtime + have a cost. And that's probably the safest way to do things anyway.
I do think though that as it seems to be only a runtime thing, it's probably warning you far too late. If it were baked in statically so, when you pulled in a new http lib (or just updated it), you approved the popup that said "let X access network and files?", it'd probably be a lot less painful 95% of the time. (since sometimes you'll want it more fine-grained)
---
Since I can't glean it from what I've skimmed so far: does SecurityManager let you do capabilities-like things? E.g. can you be given a SecurityManager as an argument, allowing code using that manager to temporarily access a file, while normally blocking it? Or is it something closer to "applies to a ClassLoader"? Though with enough effort and runtime cost you could make those equivalent, of course.
