Class libraries vs. component libraries

I consider loosely coupled
components the basic building block of development. The problem is that Java lacks the tools
for component-based development in the first place. The biggest pain point I see is
that we can't get proper encapsulation. As a result we use
class libraries in Java instead of component libraries. The drawback of class libraries is
that there's no clear boundary between the public API and
implementation details. The result is a Tower of Babel at the level of individual
classes.

A component has the following characteristics.

• It can be reused.
• It's usable in different contexts and isn't specific to one.
• It can be composed with other components.
• It maintains encapsulation through an interface.
• It can be deployed and versioned independently.

For a long time I thought OSGi was the way
forward, but I'm afraid it isn't, at least right now.
What brings OSGi down is the legacy of having
built class libraries for so long. If you try to build
an OSGi application today, you'll find that
third-party libraries aren't ready for it at all. That's without even mentioning
how difficult it is to build a web application that can be deployed as a portable
WAR archive.

Paradoxically, Enterprise JavaBeans come closest to that description,
but their use is held back by other disadvantages, such as an overly
restrictive programming model. I'm very curious to see what comes out of JSR
277, the Java Module System. Unfortunately I think we'll have the same problem as with
OSGi, at least initially, because libraries
won't be built for it. At least it will fill the gap left by the absence of a standard.

Another significant problem is that a technology
like OSGi only gives me half of what I need.
The other half is working with a dependency injection framework to control
how the component is put together
internally. Ideally the component has a defined
interface, such as a Java interface. Its implementation
is composed of several Java classes through dependency injection, and those
classes aren't visible outside the component. Nobody can
look them up. In practice that's very difficult to achieve, even
in Spring, for example.

The lack of support for pure component-based development
limits me most when working in a team. It isn't easy, for example,
to draw clear lines of responsibility. I can point to a
JAR and say it's component XYZ, but as soon as someone adds it
to their classpath, every component boundary collapses and
people use whatever the IDE's code completion offers. Individual
JARs then end up being used in unintended ways, because
nothing enforces those boundaries.

Java has a long way to go in finding the best solution. I don't think there's
any dispute that it needs one.