harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [arch] VMCore / Component Model
Date Tue, 13 Sep 2005 16:27:33 GMT
David Tanzer wrote:
> Since we already started to define some component interfaces I think we
> also should start thinking about a component model which loads / 
> connects such components. Maybe there are also some existing solutions
> we might want to look at (I must confess I didn't really search yet).

Agreed, plus managing the API itself to ensure forwards/backwards
version compatibility.

> I guess a requirement for such a component manager would be that it can
> load and connect components at runtime and that the specific 
> implementations which are loaded can be configured. It might also be
> good if the same component implementations can be linked at compile time
> (i.e. statically) which could have benefits on embedded platforms, but
> I'm not sure if we really need this.

I'm assuming that you are speculating on component management beyond the
platform support (i.e. DLL-hell). The java world is already on this path
with the OSGi framework (e.g. Felix).  It will require a non-trivial
solution to ensure that the runtime flexibility does not incur an
unacceptable runtime cost.

> Another requirement would be that the components can be written in 
> different programming languages (i.e. C, C++, Java, ...). It isn't 
> really a problem to solve this for C and C++, but can we also easily
> support other programming languages?
> 
> A simple way to implement such a component model in C would be an 
> approach similar to the one Tim Ellison described in [1] where he
> explains the structure of the J9 VM's portability library. I started
> writing a proof of concept implementation for this, and I'll add it
> to the wiki as soon as it's finished.

I look forward to seeing the proof of concept.  Were you thinking of
introducing versioning and dependency management style functions?

> It would be interesting to have several such proof-of-concept 
> implementations of component models which we can study and the decide
> which to use. We could even write "import mechanisms" for the different
> component models so they can import and use components from another
> model too (of course this would normally imply reduced performance).
> 
> Regards, David.
> 
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/%3c431866C9.705@gmail.com%3e
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message