On 12/2/10 9:59, Jeff McAffer wrote:
You are making a particular assumption about the definition of "utility class". Is the expectation that util classes never appear in API? It's not clear that everyone on this thread is working with that assumption (might just be me who is/was not). Perhaps the definition should be flipped around. util classes are, defintion, the things that a bundle uses that do not appear in their api and the bundle author did not write? That seems useful but pretty narrow.
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.
-> richard _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
