harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Migliore <enrico.migli...@fatti.com>
Subject Re: SableVM or JCHEVM?
Date Sat, 01 Apr 2006 16:44:56 GMT
Hi Etienne,

>Hi Enrico,
>SableVM's trunk ( svn co svn://svn.sablevm.org/sablevm/trunk ) is now
>licensed under the Apache License 2.0.  As SableVM is maintained by a
>number of developers, but is also used by many of my students to develop
>new VM components and do research, it was deemed more appropriate not to
>put SableVM in Harmony's repository for the following reasons:
>1- Harmony's repository is not the appropriate place for creating many,
>many branches to do academic research on VMs.
>2- Keeping a clear Intellectual Property trail would be a nightmare if
>SableVM's development and maintenance was spread over two distinct
>3- According to Geir, integration of the VM into Harmony's repository is
>not a preriquisite for J2SE certification.
ok, got it :-)

>The SableVM project has chosen to integrate our VM with Harmony's class
>library.  In particular, I have started with a student to implement
>Harmony's VMI.  Our objective is to fully adapt SableVM to work with
>Harmony's VMI "as is".  If I understand JCHEVM's approach, they are
>going in a different direction; they are developing a "GNU Classpath
>compatibility layer" so that Classpath-based VMs could migrate to
>Harmony with little effort.

>SableVM's goal is to become entirely dependent on Harmony's LUNI
>packages, as we do like Harmony's VMI.  This will have the consequence
>of breaking SableVM's compatibility to Classpath's LUNI packages.  Yet
>we do not see this as a problem;  you will still be able to use
>Classpath other packages with SableVM (awt, swing, etc.).
>So, if you wish to contribute to SableVM for helping with the Harmony
>integration, please join us at http://sablevm.org.  If you are
>interested, we'll use the SableVM developer mailing-list to coordonate
>the Harmony adaptation effort.
I, and others, ported JCHEVM to Cygwin, during the past 2 months; there 
are still a couple of things to fix, but the main work is done.

The port was made in order to be able to "study"  JCHEVM on the Windows 
platform. I understand, in fact, that having the Cygwin layer running on 
top of Windows may compromise speed performances of any JVM. In 
principle, the "-no-cygwin" option of GCC should allow us to produce an 
executable that doesn't need the cygwin1.dll library, but:

 1. I haven't yet tried to enable it
 2. The functionality of  cygwin1.dll might be embedded in the 
executable file (in this case the Cygwin layer is hidden in the .exe)

My ultimate goal, is contributing to the development of a reliable JVM 
which will run on the ARM platform, because I work in the embedded 
systems area. I don't care if  such a goal will be achieved in 2 or 3 
years, the only thing  I care is not to waste my time in volunteering on 
a thing that may be abandoned.


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message