What I read above is that Java objects are capabilities. At least, in the sense that all three rules apply to Java objects - create, transfer, divine intervention.

Yet, there is obviously something in Java that doesn't make them capabilities, else they would be used all the time. In one post in the recent cap-talk thread Mark Miller said that Java's statics were an issue. Is that all it is or is there more?

(This is certainly an interesting line of thought, along the line of David Hopwood's "definition by comparison." I'd still like to identify a single stand alone definition.)

Whoa! Look at my note again, and this time exclude the paragraph that says "For a concrete example, consider a Java VM.".

Now what you are looking at is a *general* definition. Anything which follows those rules and which you use for access control is an object-capability system. Anything which doesn't follow those rules isn't a object-capability system.

Now the question of how is a capability different to a Java object remains unanswered (in this blog entry). There is a Wiki entry about it:

http://c2.com/cgi/wiki?CapabilityOrientedProgramming

Honestly, I'm not too clear on how important are these differences between Java and Capability-Oriented-Programming. Historically, Electric Communities tried to convince Sun to close the gap back in early Java days, and failed (possibly because closing that gap would imply breaking backwards compatibility with previous versions of Java), and then Electric Communities tried to make Java libraries and idioms that closed the gap, and then Electric Communities made E.

As an aside, I think this pattern of taking libraries and idioms in Language L and then inventing Language L++ that integrates those libraries and idioms is a good way for programming languages to evolve.

"As an aside, I think this pattern of taking libraries and idioms in Language L and then inventing Language L++ that integrates those libraries and idioms is a good way for programming languages to evolve."

The problem is that capability security in a language is determined at least as much by what the language and its library leave out, as by what they support.

Besides statics (and minor problems due to being able to synchronize on any object), the most important problem with Java is that the native methods in the Java API provide considerable "ambient authority". The language does not need many changes, but commonly used parts of the API would have to be changed in ways that would break almost all non-trivial Java applications.