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: Class library componentization
Date Mon, 25 Jul 2005 11:00:02 GMT
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.

> 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.

> In some cases, my experience has been that having non-public state
> available has been a mistake.  For instance in libgcj our charset io
> code in InputStreamReader knows some details about
> BufferedInputStream.  This has turned out to be really fragile and
> we've had a number of bugs in this code over the years.
> The one area that I remember offhand as needing to be accessed by
> different packages is the stack trace infrastructure.  E.g., it is
> used by SecurityManager, by java.util.logging.Logger, by
> ResourceBundle (and more that I forget).

I don't think we (as class library developers) should be limited to Java
API for the import/export list of a component.  We should export such
internal functionality where it is going to be generally useful to
implementing other components, and manage that interface accordingly.
However, minimizing and hiding code that is purely internal to a
component would be a good thing.

> I'm not sure what this means for your breakdown ... would these
> classes need to be in the same bundle?

For the first pass I'd just make the implementation dependencies
explicit.  If it turns out that there are lots of internal dependencies
between two components then we may need to think about putting them
together in the same bundle.

> Tom


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

View raw message