Pablo: I think anemic domain model is about more than just exposing every field in a class: a domain object could very well be non-anemic and still have every field mutable, I think. Anemic is more about the operations _other_ than the setters/getters: if there are higher abstractions, its probably not anemic. If it is just a class with no operations other than changing values, then it is anemic. Otoh, it could be anemic with no setters!

I should give OSGi a serious try in order to speak with a bit more of a background. Nevertheless I believe encapsulation/information hiding is highly overrated (and IMHO underused) this days.

DI needs to break encapsulation in order to work.

More dynamic languages tend to be more flexible in this topic (in groovy for example, you can access any field, even private ones).

Even in Java, average coders tend to create an accessor/mutator pair to every field, exposing the inner components of every class (this is often called anemic domain model).

It’s true that you can achieve some level of information hiding by making classes package protected, but what you’re really doing is making the Java package your unit of abstraction. There are a number of problems with this:

* Packages are fairly fine-grained, closer to classes than JARs. To achieve the kind of encapsulation we’re talking about you would need to hide a *lot* of classes. Unless you put all of your code into a few very large packages, managing the relationships between classes inside the JAR would be difficult.

* Packages are not the unit of deployment. One of the benefits of modular JARs is that we are aligning our unit of abstraction with our unit of deployment. Because modules/bundles have public APIs, different implementations of those APIs can swapped in by deploying new JAR files. This becomes something like the relationship between interfaces and classes.

Again, I’m not arguing that you can’t achieve some level of encapsulation using package protected classes. But I would argue that it’s very difficult to build modular software in this way. One of the benefits of object-orientation was that it made it easier to things the right way than the wrong way. OSGi is the same, it almost forces you to make the right decisions. While this might be frustrating initially, I think its definitely worth it in the long run.

— Patrick

My question is: can’t this kind of ‘JAR encapsulation’ be achieved by simply choosing which classes of our JAR are public and which are private / package-private, in other words, by defining our JAR public API?

I’ve been doing this for years without a problem, and (more important) without the need for OSGi.

Based on other comments I thought that OSGi was useful only in a heavy-enterprise-application where you need to swap modules and downtime is not an option.

During development, the Eclipse compiler is completely OSGi aware and provides appropriate warning and error messages based on what packages are exposed (or not) in a bundle. The visibility of packages is set in the JAR manifest file, and these settings are used instead of what you would normally set with the Java Build Path dialog.

It works extremely well. All you need is Eclipse and the Plug-in Development Environment to get started.

— Patrick