On 12/02/2010 10:29 AM, Richard S. Hall wrote: > On 12/2/10 9:59, Jeff McAffer wrote: > Well, one thing is clear, if classes appear in your API, then you > clearly expect bundles to collaborate around those classes, so having a > bunch of bundles embedding there own copies of these classes would be > really dumb since none of them would be compatible with each other. > > I think you have to differentiate between classes for collaboration and > "utility" classes (i.e., ones not for collaboration). > >> In the end a lot depends on the numbers. How many util classes? How >> big are they? How many consumers? How many used in API (thus >> imported)? How often to they change? How many users are in your control? > > Yes, as has been said before on this thread, there is no single answer, > otherwise we'd not even be having this discussion.
Absolutely. There are a large number of issues in question. My personal feeling at this point is that, everything else being equal, a class that is used by more than a small number of other bundles should be in a separate (perhaps "utility" or "miscellaneous") bundle itself, and that the "utility" bundles should be as fine-grained as possible. Clearly, a class used in an API should be exported and clients should import the class rather than owning their own copy. Otherwise, things won't work. A class that isn't part of an API, but is useful to a bunch of other bundles *can* be exported from a single bundle or *can* be included in every bundle that uses it. To an extent, I will agree with Peter, that memory usage is not really an issue. (On the other hand, a few tens of classes times a few tens of KB times a few hundreds of bundles....) However, there are problems associated with managing a large number of binary copies of the same code. To provide a concrete example, I have a utility servlet filter that sets up a fair number of context-related attributes on incoming requests that are later used by other code; these attributes are instances of classes like String, so API issues do not come up. The processing of this filter is not complex, but there is enough involved that I have had to make and release changes to it. Having the filter in a version-numbered .jar file that is included in the applications was painful enough; I do not want to think about bad it would be to track down unversioned copies of the class included in applications. My current approach is to export the filter from a bundle and let applications import it. For one thing, modifying the filter is now a configuration change, not a code change, for the applications. That filter also provides my argument for keeping utility bundles small. A non-web-app "framework" bundle has no need to know about my filter or its changes. Having a single utility bundle ties the other bundles to code that may change more often than strictly necessary. -- Tommy M. McGuire mcgu...@crsr.net _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
