Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of dlydick@earthlink.net
 designates 207.69.195.71 as permitted sender)
Message-ID: <41200553250286130@earthlink.net>
Reply-To: dlydick@earthlink.net
From: "Dan Lydick" <dlydick@earthlink.net>
To: harmony-dev@incubator.apache.org
Cc: "dlydick" <dlydick@earthlink.net>
Subject: [arch] JFM modular structure  was: Re: [arch] The Third Way : C/C++
 and Java and lets go forward
Date: Tue, 24 May 2005 19:28:6 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII


> [Original Message]
> From: Weldon Washburn <weldonwjw@gmail.com>
> To: <harmony-dev@incubator.apache.org>
> Date: 5/24/05 4:51:16 PM
> Subject: Re: [arch] The Third Way : C/C++ and Java and lets go forward
>
> On 5/23/05, Geir Magnusson Jr. <geirm@apache.org> wrote:
> >=20
> > On May 23, 2005, at 8:23 PM, Steve Blackburn wrote:
> >=20
> > >> Lets get moving.  Comments?
> > >>
... snip...
> 
> In response to Geir's request, below is a first cut at a simple
> high-level modular structure:
> 
> 1.1)   Execution Modules
>             Execution Manager
>             Execution Engine
>             Code generator
>             Profile Collector
> 
> 1.2) GC
> 
> 1.3) Threading/sync Manager
> 
> 1.4) Platform Portability Layer (OS and HW)
> 
> 1.5) Class Libraries


I think if we gear our environment toward
GNU Classpath, probably with a "legal-stuff"
wrapper, as has been suggested, then we will
maximize its current potential and learn its
foibles.  With this experience, we can go in
and add-- even extend existing-- functionality
to meet Harmony needs.

For boot classes, etc., we will probably have
all our own stuff due to our chosen design
constraints, and I would not guess that
they supply this anyway.

> 
> 1.6) Platform Accessors
> 
> 1.7) VM Accessors
> 
> 1.8) VM Core (the hub that glues all the above modules together)
> =20
> How about starting a new thread titled [Modules & Interfaces] to
> discuss a) the definition of the JVM's modules and b) what the
> interface APIs look like?
> 
>  -- Weldon
> 


Dan Lydick