No matter whether you think you are starting with a JVM written in Java or a micro-kernel-ish one in C (which seem to be the leading options), you will probably discover that you end up writing most of it in Java. For just about every major subsystem, you will find that some of it has to be in Java anyway, and most of it turns out to be better to write in Java. Steve Blackburn mentioned some of the technical issues with respect to GC. Similar ones arise with concurrency support, reflection, IO, verification, code generation, and so on, as has been discovered by people developing both research and commercial JVMs.
One of the challenges here is that the Java programming language curently does not make it possible to distinguish those classes sitting in the JRE library (usually, the stuff in "rt.jar") that are logically part of the JVM vs the normal APIs that normal Java programmers are supposed to use. (Although most existing JVMs dynamically enforce inaccessiblity of some APIs by exploiting rules about bootclasspaths in some special cases, but this is not a general solution.) As one consequence, some people have been led to make all sorts of now-well-known complaints about developers programming to the platform-specific APIs of existing JVMs. This must be avoided in Harmony. Independently, there has been a lot of discussion lately of possible language enhancements resulting in some kind of module support for J2SE 7.0 (Yes, the one after Mustang) to provide a more general solution to the need for semi-private interfaces among subsystem-level components, as well as for similar issues that arise in layered middleware, as well as higher-level escape-from-jar-hell issues. Some people would like to see a first class module system (see for example MJ http://www.research.ibm.com/people/d/dgrove/papers/oopsla03.html, as well as similar work at Utah http://www.cs.utah.edu/flux/) Some people would like something more like a saner version of C++ "friends". I don't think that any of these have been subjected to enough thought and empirical experience to make a decision about which way to go. So it seems to me that this would be a good opportunity to harmonize: Help work on possible forms of language-based module support, work within JCP and with other JVM providers to eventually propel this into the standard, and help shape the basic structure of a second/third generation JVM. (Digression: The issues underlying all of this have long been a big concern to me, but I spent a long time fruitlessly dealing with them the wrong way. JVM providers don't want to standardize on the contents of the APIs for intrinsics etc. But they should be pleased to standardize on the way in which they are expressed.) -Doug
