Why not Java?

Why wasn't Croquet done in Java or another programming language that more of today's developers are familiar with? This is a question that often gets asked as people start to assess what it might take to begin training programmers to build metaverse applications using the Croquet SDK. In my experience, the ramp-up time for programmers already familiar with object-oriented languages is about 2-3 weeks - with the biggest challenge being that of gaining familiarity with all the new and unique classes.

Basically, the reason for using Squeak instead of Java as the basis for Croquet is because Croquet required a number of capabilities that could only be provided by a true late bound, message sending language. Croquet's relationship to Squeak gives Croquet the property of a purely object-oriented system which allows for significant flexibility in the design and the nature of the protocols and architectures that have been developed for the system.

Squeak's ability to keep the system running while testing, and especially while making changes, is an essential part of the Croquet collaborative development capability - a capability in which programmers can modify the code running the environment while the environment is running. Another key feature of Squeak is its generalized storage allocator and garbage collector that is efficient in real-time. This allows for; 1) animations and dynamic media of many kinds to be played while the garbage collector is collecting, and 2) reshaping of objects to be done safely.

Here's a quote from Alan Kay taken from a 2005 ACM Queue interview in which Alan addresses the choice of languages:

"Now just to mention a couple of things about Java: it really doesn’t have a full meta-system. It has always had the problem—for a variety of reasons—of having two regimes, not one regime. It has things that aren’t objects, and it has things that it calls objects. It has real difficulty in being dynamic. It has a garbage collector. So what? Those have been around for a long time. But it’s not that great at adding to itself.

For many years, the development kits for Java were done in C++. That is a telling thing.

We looked at Java very closely in 1995 when we were starting on a major set of implementations, just because it’s a lot of work to do a viable language kernel. The thing we liked least about Java was the way it was implemented. It had this old idea, which has never worked, of having a set of paper specs, having to implement the VM (virtual machine) to the paper specs, and then having benchmarks that try to validate what you’ve just implemented—and that has never resulted in a completely compatible system.

The technique that we had for Smalltalk was to write the VM in itself, so there’s a Smalltalk simulator of the VM that was essentially the only specification of the VM. You could debug and you could answer any question about what the VM would do by submitting stuff to it, and you made every change that you were going to make to the VM by changing the simulator. After you had gotten everything debugged the way you wanted, you pushed the button and it would generate, without human hands touching it, a mathematically correct version of C that would go on whatever platform you were trying to get onto.

The result is that this system today, called Squeak, runs identically on more than two dozen platforms. Java does not do that. If you think about what the Internet means, it means you have to run identically on everything that is hooked to the Internet. So Java, to me, has always violated one of the prime things about software engineering in the world of the Internet.

Once we realized that Java was likely not to be compatible from platform to platform, we basically said we’ll generate our own system that is absolutely compatible from platform to platform, and that’s what we did."