I suppose actually OSGI gives more freedom in this issue than current
approaches, since each module basically declares its own exports. So you can
actually have "public" classes within your implementation that are not
exposed.

To me, it seems like the implications of this is that you do not want to
pollute the interface/implementation of any class that is publicly exposed
(or a candidate for being so in the future) with anything slightly-public
(such as a protected method or package-level protection), but as long as you
keep it in a separate class file (in a separate "internal" package or just
beside the implementation), you're home free - ot at least it's more a
question of preference? Is there any such preference ?

Reply via email to