Hi Philip,
Thanks for the comment. You ask very pertinent questions. >> This is a good practice that OSGi helps with a lot. > Can you be more specific about private packages. Is this entirely an OSGI > idea. Well, yes and no. No in the sense that it is a fairly well-known good practice (to the extent that any practice is debatable according to the circumstances). I will write more about this below. Yes in the sense that OSGi enforces the separation. Public packages are available to any other bundle that imports those packages, while private packages are “hidden” from other bundles, and are only available to the bundle in which they reside. (“Private” means “private to its own bundle.) It just helps keeping larger systems under control better. Also no in the sense that just because a module follows these practices and is “OSGi-enabled”, it does not at all force anybody to use OSGi if they don’t want to. All you would need to do is (one way or another) instantiate the implementation class directly rather than having the OSGi framework do it for you. However you are doing this now would not have to change. Note that I am making the big assumption that there is a well-known interface to implement in Mime4j, and that the implementation classes *can* be hidden. If this is a library that is actually intended to be completely exposed, then my comment about separating interface from implementation is not valid. I have only taken a cursory glance, and my initial impression is that moving out the implementation could be useful. > Can you also be specific about perceived benefits. I assume this would > involve lots of bloat in terms of new wrappers and refactoring downstream > projects to match the new API with no functional benefit. Actually, assuming that the “API” consists mostly of interfaces, there should be no change at all to those interfaces. It is only the implementation classes that would get moved to a different package. As I mention above, if the intent was to directly use the implementation classes, then this is a “library” and my proposal is not valid. However, if people are directly using classes that normally they should not be using, then by making this separation it would make it clearer what is the public API, and what is intended to be private. In that case, if people are using the public API, there ought to be no change at all. Otherwise, people actually **ought** to stop directly using implementation classes, so they **ought** to refactor their code to use the API properly. But I am making big statements here without knowing Mime4j well enough. Again, I would have to evaluate the code. You ask great questions, and I realize that maybe I should have investigated more first before shooting out my question here. :-) What I will do before writing any more is try a sample of the kind of changes I am referring to. It would be much easier to take a look at the actual changes than to have an abstract discussion without referring to code. Thanks for engaging. I’ll get back to you soon either with some code changes, or with the understanding that my proposal is wrong. Cheers, =David
