harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Tromey <tro...@redhat.com>
Subject Re: Class library componentization
Date Fri, 22 Jul 2005 19:35:31 GMT
>>>>> "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.

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

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'm not sure what this means for your breakdown ... would these
classes need to be in the same bundle?

Tom

Mime
View raw message