harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Tromey <tro...@redhat.com>
Subject Re: Assembled comments from the web
Date Sat, 07 May 2005 18:19:39 GMT
>>>>> "Henri" == Henri Yandell <flamefew@gmail.com> writes:

Henri> 1) Use Parrot.

LLVM is probably a better choice, if it comes to that.
But looking at execution engines is probably premature.

Henri> 5) Have Sun open-source things to Harmony, or IBM.

Would be nice.

Henri> 6) Will generics be truly in the .class files and not just a
Henri> compiler hack?

If you want something that is really java, then you end up having to
stick to what java does, even if it seems like a mistake.  In
particular you can't really improve generics, because the differences
would be detectable by user programs.

Henri> 10) Does the TCK test serialization compatibility, or should that be
Henri> something that gets created, a large test that compares two J2SEs for
Henri> compatibility?

I don't know about the TCK, but Mauve already includes some
serialization tests, and of course we're happy to have people add

Henri> 11) It would be interesting to see a document with areas for vendor
Henri> improvement.

Some of the tasks here involve ways to better integrate the class
libraries with other free software projects:


If you want to build a really configurable VM, I think it makes sense
to consider breaking down the whole package into a few different
parts: the "core" VM (stuff like runtime linking, other low-level java
semantics, object layout, exception handling approach), the execution
engine (jit, interpreter, whatever), the garbage collector, the class
library, and the OS interface.  Making it possible to mix-and-match
these, or to say configure from a very tiny embedded VM up to a
server-type recompiling JIT, is not trivial, as these areas are not
completely independent.  You can see some discussion of a few of the
issues in this thread:


It would be nice to have some kind of reusable, configurable core VM.
Perhaps we could eliminate one of the current areas of divergence this
way, by letting (eg) kaffe/sable/jamvm/libgcj share more bits.


View raw message