Presentation: Modular Java Development in Action

We do some of that as well at Luminis, but the products that I'm currently working on heavily use OSGi, which is a modular technology for Java applications. We do that because we build products instead of projects. We have learned the hard way that creating products means you need to be maintainable, you need to be extensible and not just for the first few months or the first year, but for many many years to come. And modularity helps us in that, where OSGi is a tool that helps us to translate modular designs into actual code.

If you have a Spring application you have maybe one JAR or multiple JAR files containing your application code, and these are services which use other services. Dependency injection is used to instantiate these services and inject them into other services. Typically Spring takes care of this by doing all the hard work for you, and it uses reflection to, for example, inject a service implementation into a private field of your class. On the classpath this isn't really an issue because every piece of code can use any piece of code, and if there's something private on there you can use reflection to bypass any access restrictions that Java puts on this code. Now what happens if you move to modules? You get what we call strong encapsulation where we can actually hide code inside of a module. And the service implementations that you use in your application are particularly relevant to hiding because you don't want people to code to these implementations, you want them to code to your interfaces. But what happens if you hide these implementations inside your module? They are also hidden from the frameworks that are trying to access it reflectively, because we're now in a modular world. If your application module doesn't export this service class then Spring won't be able to pry its way into it and to inject into a private field of this class. One solution will be to say, OK, if that's the case, then we probably would have to export this service implementation from my module because Spring uses it, but doing so you're voiding the advantages that modules give you. That is really not a nice solution.

Yeah, that's right. Java developers will definitely need to know what it means to do modular development. But at the same time, modularity as a principle lives at the architecture level. When you design and architect applications, at the whiteboard level you start thinking about boundaries, about modules, etc. And previously, it ended there. As an architect you could opt to use OSGi to translate these module boundaries from the whiteboard into code. But, let's be honest, not many people do that. With the Java module system being part of the platform, and being part of the language itself, I think the barrier of entry is lower for architects to define module boundaries and also have them end up in code.