interfaces?).
Aaron
Jeroen Frijters wrote:
You are correct, but why take the performance and complexity hit to
solve a non-existing problem?
Regards,
Jeroen
-Original Message-
From: Aaron Hamid [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 05, 2005 20:44
To: harmony-dev
Gah. :(
So if I am to understand this correctly: Classpath java.lang.* implementation does not rely on specifics of
any given VM* interface implementation, but said VM* interface implementations MAY rely on internals of
existing Classpath java.lang.* classes? (so there is a one-way dependency
I actually had not considered this issue which would seem to warrant
these classes living in the same package. But can not an equivalent
solution be constructed such that the implementations of these public
classes can hand the VM* classes references to internal structures (and
vice versa)
As a purely idle bystander and armchair speculator, I'm with Steve on this one. It seems the community has roughly aggregated into
VM in Java and VM in C/C++ camps. Both camps appear to have large and robust support and actual working
implementations behind them. In the former I see JikesRVM
will take
care of most of the other decisions for us.
-Andy
Aaron Hamid wrote:
As a purely idle bystander and armchair speculator, I'm with Steve on
this one. It seems the community has roughly aggregated into VM in
Java and VM in C/C++ camps. Both camps appear to have large and
robust support
It would be great if everyone would agree on a single architecture and
plan, and it would be great if everyone, despite their personal
preference, committed to working on that single VM; but since that has
not (yet?) happened, there are people willing to work, there are several
robust
