Tom Tromey wrote: >>>>>>"Tim" == Tim Ellison <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
