> For use case 1, my main concern is as described before : A wants to > use objects of class B, that's all. > Whether B is implemented "monolitically", copy/pasting all > implementation code in a single class file, or by composition or > through extending some base class, > should preferably be a localized implementation decision of the B developer. > The A developer should need to be confronted with this, I think.
In your example: A uses B, B extends C; an object of type B is also an object of type C. So to compile A, the compiler must "see" B and C. The same is true at runtime especially for the verifier. Assuming B and C are in different packages (pb and pc, respectively), the export package for pb must state it uses pc. This makes sure that when the bundle containing A imports pc, it imports the same pc as the bundle which exports pb. > > It's similar to when you write "plain" Java code. > When you need class B, you just add one import statement in your A > src file, to import B. You don't need to add import statements for > all base classes in B's class hierarchy... True, BUT the compiler must be able to see all of B's class hierarchy. Since a B is-a C. You cannot compile A unless the compiler can also see C. > Stated differently : what does an export-package do for a bundle? > Does it export just the "fragment" of the classes in the package, > corresponding to the specific interface/source code in there? > Or does it export a full "view" on the classes? > (this is of course not an easy problem, and is indeed related to > transitive dependency mgmt at compile/run time as mentioned by > someone before etc...) The export package makes the complete contents of that package visible to any wired importer. The exported package may use other packages that the importer of the exported package will also need to import. > > Or still otherwise said : if I really am not using any C-related > types in my A, why would I need to depend on it? But you are using C. Since a B is-a C. You may not directly call it a C in the A source code but when you construct a B, a constructor of C is called. > If I am using such types, it would indeed be logical that I need to > formalize that in my MANIFEST, else it seems to be a total > encapsulation-killer? In this example, the designer of B made an explicit choice to extend C and thus "use" C which makes all importers of pb also dependent on pc since pb is dependent on pc. This is why you must carefully use inheritance since you impose dependencies on your consumer. > > And that last line-of-thought is also what's in my mind for use case 2... > > For your questions : > - A may indeed not be interested in the C-methods. But to stretch > the discussion even a bit further ;-), even if it would, and it > accesses those methods through B, why exposing a dependency to C at all? > (again, in plain Java src code I wouldn't even be aware of C, I > would just be using/referring objects of class B) -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
