Why not use Java for Open Cobalt?
When we first set out to build Open Cobalt’s underlying Croquet architecture, we intended to do it in Java. However, we had to abandon that approach because Java lacked needed meta facilities. Open Cobalt relies heavily on the Smalltalk meta system and accessible internals. For example, part of the Open Cobalt system is #future interface for sending messages into the replicated islands. It is an uncluttered interface that reads naturally. Now consider the issues of translating this in to Java. First, Java will not let you write a general “message interceptor pattern” which means you’re going have to rewrite the sending sequence repeatedly in the calling section instead of the graceful encapsulation #future provides. Secondly, Java requires that you statically type everything this greatly increases the complexity of marshaling and unmarshaling arguments and of the support code required. Now consider implementing a timed message queue; you’d have to write inner classes with serialization
