In this chapter, we will start to go through some basic OSGi concepts. While we want to get you writing useful code as soon as possible, it is helpful to know what is going on behind the scenes.
As discussed in Chapter 1, one of the most important concepts for achieving modularity is to promote cohesion and prevent coupling. For code that you write yourself, this is easy; just don’t use implementation classes. For code written by others, this is a lot more difficult. How do you know what code is implementation code in the first place? Java comes up short here. Of course we have access modifiers in Java, but they are defined in a way that makes them hardly usable in a modularity context.
Within parts of an application, there is always some coupling between classes. This is fine, as long as those classes together are usable as a cohesive module. If there would be no coupling at all, it would be impossible to create any useful code. To be able to use other classes, these classes effectively must be public in Java. Although there are access modifiers like private and protected, these access modifiers don’t support the concept of isolating modules. They either constrain usage within a module too much or don’t constrain external usage sufficiently.
If classes within a module are public, how do we prevent classes that are not part of the module to accidentally use implementation classes? How do we make sure that the cohesion of a module ...