harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: Java
Date Sun, 15 May 2005 15:19:23 GMT

On May 11, 2005, at 6:01 AM, Lee Morgan wrote:

> I worked on a project where we ported a few different VM's to the  
> cold-fire processor of years back, that may or may not prevent me  
> from contributing to this project due to IP conflicts (please advise),

That will be a different thread - we need to start establishing  
ground rules for participation.  Clearly there will be two kinds of  
participation -

a) Helping with the design work, which will be for you to decide if  
and where you are violating non-disclosure, etc.  We might want to  
put some process framework around this aspect.

b) Contributing code.  Here we *definitely* will put process  
framework to ensure those that can't contribute to sections of the  
project won't be able to in an auditable, provable way.

Again, this will be a new thread Coming Soon  :)

> does the project intend for the VM to be suitable to run on  
> resource constrained devices?

I would like to see it, but you are also "the project", so if you  
want to see it, lets make it happen.

> and therefore be a suitable platform for the CLDC.  I know that  
> Linux is being used more and more in embedded systems and if we  
> focus on small footprint everyone benefits.
> I would like to aim big:
> Full compliance (J2SE and then J2EE)
> Small footprint core written in C
> Small number of non portable functions to minimise porting overhead
> Plug-gable garbage collectors (one similar to train that uses a  
> swap file-system for old objects might be nice)
> And why not a version that sits at the kernel level like TUX for  
> maximum performance.
> Class libraries implemented in whatever way the contributor would  
> like, native implementations for some platforms, pure Java where  
> possible.
> We could start with pure Java implementations to get something  
> working and then consider native implementations for the parts that  
> really need it.
> I think the key is for it have as broad appeal as possible, and to  
> suit as many contributors as possible.



> - Lee

Geir Magnusson Jr                                  +1-203-665-6437

View raw message