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: Class library componentization
Date Mon, 25 Jul 2005 13:36:49 GMT

On Jul 25, 2005, at 7:00 AM, Tim Ellison wrote:

> Tom Tromey wrote:
>>>>>>> "Tim" == Tim Ellison <t.p.ellison@gmail.com> writes:
>> Just some random thoughts on this.
>> Tim> The goal is to (a) stimulate discussion, and (b) think about the
>> Tim> components that we should declare with well-defined  
>> interfaces to other
>> Tim> components (I'm thinking of OSGi bundles here).
>> In most cases I think places where one package needs another can be
>> implemented solely with the public API.  However there do seem to be
>> a few cases where it is convenient to share across package
>> boundaries.
> I don't think that a _package_ is the right level of componentization,
> which is why I tried to group sets of packages into a single  
> component.
>  I agree that in most places the implementation of a component is
> primarily though public APIs on other components.  So, for example,  
> the
> public APIs would be exported from the OSGi bundle, but the
> implementation would remain mostly hidden.

I assume that what we really need is two kinds of component export,  
the public app level API (java.util.*) and a public-yet-not-for-app- 
but-fellow-traveler API, such as what other conspiring modules would  
export to each other to provide  the full public API.

Kinda like "friend API" w/o the horror of having to declare who your  
friends are...

>> Some of this depends on exactly how you want to implement things.
>> E.g., in Classpath we implement java.io primitives in terms of
>> java.nio.  You could do this differently of course, but maybe you'd
>> want to somehow share the native layer.  (A similar example has to do
>> with charset conversion; in Classpath everything is done with nio,  
>> but
>> libgcj for instance has its own approach *and* the nio code.)
> Agreed, and if we are explicit about what a particular component
> provides by its public API, and what it needs to import from others'
> public API, we can mix and match implementations (i.e. versions)  
> robustly.

Sure - Can we also version the supported public-for-friend API in  
some way?  (I need to go read the OSGi spec...)

Geir Magnusson Jr                                  +1-203-665-6437

View raw message