Extended stack introspection requires some complex changes to the virtual machine. As before, changes to the JVM could destabilize the whole system. Each class to be protected must explicitly consult the security system to see if it has been invoked by an authorized party. This check adds exactly one line of code, so its complexity is analogous to the configuration table in name space management. And, as with name space management, any security-relevant class which has not been modified to consult the security system can be an avenue for system compromise.
Unmodified capabilities are also quite simple, but they have well-known problems with confinement (see section 4.3). A capability system modified to control the propagation of capabilities would have a more complex implementation, possibly requiring stack introspection or name space management to work properly. A fully capability-based Java would additionally require redesigning the Java class libraries to present a capability-style interface -- a significant departure from the current APIs, although capability-style classes (``factories'') are used internally in some Java APIs.
An interesting issue with all three systems is how well they enable code auditing -- how easy it is for an implementor to study the code and gain confidence in its correctness. Name space management includes a nice list of classes which must be inspected for correctness. With both capabilities and stack introspection, simple text searching tools such as grep can locate where privileges are acquired, and the propagation of these privileges must be carefully studied by hand. Capabilities can potentially propagate anywhere in the system. Stack annotations, however, are much more limited in their ability to propagate.