harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Wielaard <m...@klomp.org>
Subject Re: Harmony: project purpose
Date Sat, 07 May 2005 11:11:00 GMT
Hi (moved to harmonay list since it is just a list of teechnical

On Fri, 2005-05-06 at 23:02 -0400, Geir Magnusson Jr. wrote:
> On May 6, 2005, at 10:54 PM, Simon Kitching wrote:
> > Without that, only general "design
> > principles" can be shared between Harmony and these projects, which
> > really isn't of much use in the Classpath case as the classes must
> > adhere to the Sun TCK which must be pretty detailed on library class
> > behaviour.
> Except that it's my understanding that the GNU "family" of projects  
> (Kaffe, GNU Classpath, GCJ, etc) all want to use GNU Classpath, and  
> are working out how to make it pluggable and modular.  We need the  
> same thing (would be great to have a VM that we could plug a  
> different classlibrary into to get J2ME, for example), so why not  
> work together?  Then when we get past the license problem, we can  
> intermix.

Yes. And I urge everybody to take a look at the current projects around
GNU Classpath and how they integrated different parts:

When Geir proposed the Harmony project to me and asked if I was
interested in helping out defining bridges I send the following
referrences that I think will benefit the project:

   GNU Classpath VM Integration Guide

   Hacking on the VM Interface workshop slides
   Both are a bot out of date, it would be good to update them
   again. Currently the vm/reference source code in a recent GNU
   Classpath release tarbal should give you a better impression.
   There is of course the binary compatibility ABI for GCJ:
   I don't know if there are documents on the shared bytecode
   verifier ideas that some people talked about. The verifier exists in
   pluggable form on the gcjx branch of the GCC cvs repository.
   Both gcj and kaffe now (can) use the boehmgc.
   Mauve http://sources.redhat.com/mauve/ contains tests for the
   various parts (language, core-libraries, jit, visual AWT tester,
   BC). JikesRVM comes with a JNI testframework.
   The CNI used to bind classes/methods written in c++ and java in
   gcj is described at:
   There have been talks about sharing parts of the JDWP and JVMTI
   layers/interfaces. Most of the wire-protocol at least can be
   shared. I have some designs for that, but I forgot who is
   working on this for gcj.
   GNU Classpath Tools provides some tools (like gjdoc) that
   runtimes can share



Escape the Java Trap with GNU Classpath!

Join the community at http://planet.classpath.org/

View raw message