harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew French" <matt...@camary.co.za>
Subject RE: Against using Java to implement Java (Was: Java)
Date Fri, 13 May 2005 09:06:12 GMT
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

View raw message