harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Brooks" <jmb_perso...@hotmail.com>
Subject RE: Against using Java to implement Java (Was: Java)
Date Fri, 13 May 2005 03:02:10 GMT
>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! 

View raw message