I hope you use C to write the VM for Harmony.
The chief objection I have to using C to write the VM is that it introduces a host of common errors and delays associated with using C or C++ for large products. C is an excellent language for its purposes, but this isn't 1972. Java was created to resolve a number of problems that arose from the ever-growing design of C++, which I swear is rapidly becoming the new PL/1. We could use a restricted subset of C++ I guess, but a lot of "gee-whiz" features would have to be left out to assure cross-platform compatibility. So why not use Java?
The reason is, that I think, that the best is, if Harmony is nearly 100% compatible to Suns Java.
That won't be determined by what language the VM is written in.
If you write the VM in Java itself, then there existing some problems:
1. you need a native-code compiler (like gcj) to create it. And if Harmony itself is a native-code compiler it is not 100% compatible to Suns JVM.
I'm not sure why you believe this. I think some people are confused about this. Initial builds will have to be bootstrapped on another VM until the build-environment becomes self-hosting, at which point, it will not be necessary to use another VM.
This is the case with PyPy, SBCL, and many other bytecode-intepreted self-hosting implementations of a language platform in the language itself. My response to your other comments is in the same vein. C itself is a high level language (it isn't assembler or machine code). The GCC compiler and glibc are written in C. How do you think this came to be? What about that chicken and its egg? Really, it is simple. Until the build environment became self-hosting, it was written using another tool; once it became self-hosting, it could be expanded and extended on itself.
That being said, I think we are all whispering in the wind here. I'm prepared to work in C or C++ if that's what we are using. Ultimately, a toolset is just a toolset, and that includes the language or languages used. Not all languages are equal however; we need to think outside the box a little if we are intent on increasing the chances of success. What is our problem domain here? If the JLS and JVMS, together with the TCK, are our requirements documents, then we could use almost any toolset, and the issue becomes one of reliability and maintainability.
I assume that there is a project lead or leads associated with this coming from the Apache project, and they will make the determination of these initial matters.
So speak up project lead(s). We are here. We are talking a lot, but not much is happening. Order us about. Assign work. Let's get our hands dirty. The likelihood is that there will be changes along the way anyhow. There almost always are, and developers dedicated to the project will simply have to adapt.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
