harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Heath <steve.he...@gmail.com>
Subject Re: Against using Java to implement Java (Was: Java)
Date Fri, 13 May 2005 09:51:54 GMT
Isn't it a good idea to write the first implementation in a functional
programming language (read the wizard book)? That's what these
platforms are designed for and the constructs are there to help in
designing the thing. Then when you're happy you know what's good and
bad you can re-code it in something that actually runs fast. I'm aware
of a reasonable amount of literature that talks about GC and
interpretation techniques that uses languages such as ML and Scheme.

Compiled Java initially seems as good as anything, but don't those
compilers add in their own brand of GC? Wouldn't that be an overhead
we neiter need nor want? Do we want to generate our own native
compiler? I'm thinking the best native compiler/language to use is
probably C.

I agree that most of the libraries can be written in Java, but
wouldn't that constitute a separate apache project, just like GNU
Classpath? The VM should probably be as clean as a very clean thing...
in a clean room.. (hence why I never mentioned C++ :)

On 5/13/05, Matthew French <matthew@camary.co.za> wrote:
> Mark Brooks said:
> > 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.
> 
> Hmmm. First I would argue that a VM is not a big project. Extraordinarily
> complex, yes. But not big.
> 
> Secondly, the common errors and problems related to C usually are the
> result of pointers, memory management and complexity. But I don't see how
> we can get away from these using Java. The whole point of using a VM is to
> hide this functionality from the application, which means by definition we
> have to implement it in the VM.
> 
> Then Bob said:
> >>> IMHO both JITs and pre-compiling have their place.. it
> >>> depends on the application whether one is definitely better
> >>> than the other.
> >
> > This is a recipe for a bloated system that never works.
> 
> Agreed. Which is why we should try and avoid bloat. :)
> 
> But it seems to me the reason behind the wide range of alternate VM's is
> because each of these has a specific niche to fill. If Harmony is intended
> to bring these efforts together, then I would think that some "bloat" is
> inevitable. Not performance bloat, mind you, just added complexity.
> 
> My hope is that by clamping down on this complexity early [did I mention
> architecture? :) ] we will not only remove the bloat but make the task
> even less complex than it is now. (FWIW: I am working on a document, but
> it has taken on a life of its own. Hope to finish over the weekend)
> 
> > Also, most app
> > programmers don't want to worry about the details of how their program
> > is compiled.
> 
> This is dangerous territory: a person who does not know how their car
> moves will eventually run out of petrol.
> 
> Java users, whether they like it or not, will eventually be confronted
> with some implementation details. Our role should be to make such issues
> transparent, not hide them. By doing so we would be reducing the time and
> effort to resolve such issues.
> 
> This does not mean someone needs to read a 200 page tome just to run Java.
> Hopefully the quick start guide will contain just one line...
> 
> Ben Laurie said:
> > Mark Brooks wrote:
> >>> I hope you use C to write the VM for Harmony.
> >
> > I've tried to sell C++ in the ASF many times. Even back when it wasn't
> > quite so bloated as it is now it wasn't a popular idea. Far fewer people
> > can write C++ than C, and hardly any of those can write _good_ C++.
> >
> > So, I think we'll end up back at C.
> 
> As much as I like C++, I would have to agree that C should be the default.
> 
> But I am still thinking that we can make it so that we have a choice of
> multiple VM's - which can be written in C, C++, Java, .Net, Perl, Python
> or whatever other language takes the authors fancy. I can see many valid
> reasons why we would want to do this, but the trick is getting it to work
> without adding enormous complexity.
> 
> > As I've said before, I'd like to see
> > a framework that _allows_ most of the VM to be run in Java (or Python,
> > or Perl, or Erlang, or whatever-floats-your-boat), but doesn't require it.
> 
> The bulk of a Java environment is the API/libraries. I would like to see
> the  libraries written in Java as much as possible. For example, LDAP
> functionality can be written entirely in Java. You just need to talk the
> right binary language.
> 
> Same applies to parts of the maths API like BigDecimal, date functionality
> (except some cases like getting the system date), XML classes, the bulk of
> the IO classes, etc. We should rely on the VM to optimise the Java code -
> I see no reason why an efficient VM cannot match C code or assembler in
> most cases.
> 
> There are exceptions: for example, advanced maths like sin() or a bulk
> block copy will perform much better using hardware. Even then, I think it
> could be useful to have implementations of these functions written in
> Java, and the ability to override them.
> 
> How is Classpath done? Is the bulk of the code implemented in C and
> wrapped in Java? Or is it Java with a thin C api?
> 
> - Matthew
> 
>

Mime
View raw message