Reading blogs about Java modularization gives me the sincere impression that (too) few people understand what modularization really is all about and how OSGi implements it.
Modularization is a fractal, it is a process that has happened several times over the last 50 years. The reason for these disruptive process was that it allowed us to scale software development to the next level. Assembly was a clear form of modularization where the bits were hidden from us humans. Functions with local variables were the next step. The industry then went on with modules (functions + data) and objects that are basically modules that could be instantiated. Java added packages, which grouped classes, again a form of modularization.
What these efforts did was encapsulate, they created a boundary between inside and outside and controlled the internal name space by importing and exporting. You could import from the outside world and you could control what was exported. What you did on the inside was your problem, it was not visible to the outside world. For example, it is impossible to detect that the name of a local variable used in a function. This kind of encapsulation is important, it means what happens in the inside is invisible to other parts of the system. Invisibility is good, you can't be wrong about something you do not know!
Except for OSGi, other modularity efforts seem to forget about this crucial encapsulation required for the next modularization step. The efforts I've seen so far focus on accessibility. The difference between accessibility and visibility is that accessibility requires a single name space. Where in OSGi each bundle (the module) has its own name space as we've done in the past when we took a modularization step, in other forms this aspect is ignored. All other proposals I've seen so far assume that there is a single name space for classes.
A single name space works well for small to medium systems. However, today we are building systems that consists of a large number of subsystems. Forcing a single name space on these large systems is in the long run asking for problems. The clearest example is if you have two subsystems that depend on different versions of a third subsystem than you're in trouble. Unless you build on OSGi.
Peter Kriens
No comments:
Post a Comment