harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Moving forward - call for contributions
Date Mon, 01 Aug 2005 12:39:33 GMT
Ok - it's been a week with no major grousing about the contribution  
framework (we'll still of course accept comments from the larger  
Incubator and ASF community and react accordingly), but lets get  
started in deciding next steps.  We're still debating issues around  
the mail list policy (which has grown to code repository policy over  
on the Incubator list, but lets not let that stop us from moving  
forward for now.)  I'm not sure we're done, but getting actual use  
cases to handle will help us iron out the process and policy.  At all  
times we should be as conservative as possible, but lets get going.

The following are how I think things break down, I'd like to renew a  
call for contributions in the following areas (and any not mentioned) :

VM and Parts

I think (and others think) we have at least a two-phased approach to  
what we'll do with VM and related for the project :

1) Near term : Purpose is to have a basis for working on the  
modularity while having working code.  We should solicit one or more  
contributions in both C/C++ and Java to let people work on what they  
want and be understanding that in all probability, it will be a  
prototype.  I personally would like to see us get a donation of

- JikesRVM and related projects
- an existing non-java VM, like Jam or others.
- anything Dan Lydick may want to throw our way, as it may be easier  
to grok for us newbies and refactor as our modularity story develops

In each case, we could either accept a community moving over here, or  
accept a copyright license in order to limit the risk to an existing  
community.  (For example, the research people that depend on JikesRVM  
may not wish to have their work disrupted, but if things take off for  
our JikesRVM "branch", then they may migrate over here.  Same with  
the JamVM community, if they were to grant us a copy to start working  

2) Long Term : Our ultimate long-term goal is a platform competitive  
with the commercial offerings.  I suspect we won't be able to evolve  
what we have from "Near Term" above, but rather will use Near Term to  
decide on our architecture, and take a fresh run using pieces from  
Near Term.  Maybe not, of course, but we should understand this a  
very possible path.


We need all the standard tooling (e.g. compiler).  Mark sent out a  
nice list that I think we should just boil down and get to work on  
using/adopting.  See his post from July 22, but I summarize here :

- compiler: Several candidates. (jikes, ecj, gcj)
- javadoc replacement.
- browser plug-in.
- jar replacement.
- javah replacement.
- native2ascii replacement.
- javap replacement.
- serialver replacement.
- rmic and rmiregistry

Class Library

There are a few aspects to this.

First, we have two approaches to class library / VM interface, and  
with a VM contribution, it would be nice to try both.  Tim and Graeme  
have discussed how J9 does it, and we have a decent understanding of  
how GNU Classpath does it.  If we had a VM - even a simple one - we  
could start toying with the two.  That would require at least a toy  
classlib here to use the IBM/J9 approach, and hopefully we could  
derive an interface to standardize on.

Second, the modularity issues (JSR-277, OSGi) are important topics  
right now.  An OSGi implementation may/is/will be incubating at the  
Apache Incubator, and the ASF is going to participate in JSR-277,  
mixing several interest groups, such as ourselves and Apache Maven.   
Anyone interested in thinking and working on that is invited to do so  

What else?  Thoughts?

Geir Magnusson Jr                                  +1-203-665-6437

View raw message