Allen Davis of KSC - the goal is to run Smalltalk unchanged on the JVM. This thing compiles Smalltalk code into Java byte code (.class files).

• Java code from Smalltalk code
• Smalltalk callable from Java
• Java Subclassing from Smalltalk
• Execution in the Java environment
• Full support for Smaltalk blocks
• Support for JITs
• "Do anything in Smalltalk that could be done in Java"

They had to implement a metaclass layer, since Java classes aren't objects - to quote - "polymorphism is completely broken on the Java class side". So a Smalltalk class in this system is not a Java class - it's an instance of a Java class. Going back to the Blue Book, they recreated the same hierarchy of metaclasses that exists in Smalltalk. They had to do this for multiple reasons, not least so that you get real inherited lookup of methods on the class side.

So a few of the hard questions - how do you get performant blocks in this kind of system? One possibility (ugly) is inner classes. There are scope resolutions with respect to variables though - compilers will bark at modifying variables based on where they are declared. So, you could create Context objects to dodge around that issue - this allows values to be changed within the inner class. That gets complicated though.

For blocks defined in a particular method for a class, they defined as methods for that class and use Context objects to get around the issue above. The next problem - type constraints. Allen says that they have gotten around this problem, getting static behavior even within a dynamic environment.What they do is push method implementations up to a common implementor in the inheritance chain, using "synthetic methods" (a feature Java allows, and most tools hide). They didn't do anything with Java interfaces. The common nheritor has a #doesNotUnderstand: that sorts it all out.

There's a good question - what about #perform? Same thing as above - the common inheritor has a #doesNotUnderstand: implementation that sorts it out. In many cases, they can just inline those. They use reflection in other cases and then cache the results to improve performance.

What about exception handling? Here the ST on the JVM approach is using Java handling - so by the time it gets back up to the recovery point, you no longer have the stack (so, no Seaside on this implementation). This is more akin to the VA Smalltalk behavior, rather than the VW/Squeak behavior.

The main thing - they are making the code available under the LGPL (unless someone comes up with a better license to use - the choice of license was a hard question). Full crowd - interested audience for this one. "The code is self documenting" - heh. Questions? Send them to Allen.