Presentation: Modular Java Development in Action

Track: Evolving Java and the JVM: Mobile, Micro and Modular

Location: Churchill, G flr.

Duration: 2:55pm - 3:45pm

Day of week: Wednesday

Level: Intermediate

Share this on:

What You’ll Learn

  • Hear about modules introduced with Java 9 and why you should use them.

  • Learn how to use Java’s module system, to create maintainable and extensible applications.

  • Find out what issues you can encounter when moving to Java 9 and how to address them.


Since Java 9, a brand new module system is part of the Java platform. This isn’t your average language feature: making the most out of it may involve rewiring your brain. In this session we explore the benefits of a modular codebase using Java 9 modules. After reviewing the basic concepts of modules, we’ll look at what it means to take an existing application to this new modular world. Features like automatic modules and open modules will have no secrets for you after such a migration. Want examples? We’ve got plenty in this practical and code-driven talk. You'll be ready to explore modular development in Java before you know it.


What's the focus of the work that you do at Luminis today?


I work as a software architect at Luminis, and I've been developing Java-based applications for more than 10 years. Currently I'm working on a system that revolves around personalized learning for Dutch secondary schools. We're building web applications and matching back-ends that do data analysis, all in order to improve education. We are doing that using the Java platform.


What kind of stack are you using? You mentioned earlier Spring, Hibernate.


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.


Is your talk an introduction to Jigsaw (the Java module system) or are you going to go deeper?


No, it won't be an introductory talk. We're going to take an existing application that uses many popular open source libraries, like for example Spring and Hibernates, a typical enterprise application. And we're going to look at what it takes to take this application from Java 8 or earlier classpath situation to Java 9. And when we’re on Java 9, we want to use modules, so we're going to learn about Java modules. You will encounter some issues when doing that, and we will address those. These are actual real world issues because many people are using Spring and Hibernate and other frameworks that rely on those same principles, using reflection under the hood, etc. These are all things that you'll run into when you move to modules.


You mentioned reflection. Can you give an example you might run into when moving from the classpath to module system and maybe how you'll address that on the talk?


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.

What you can do, and what we'll look at in the talk, is to use a concept called open modules. You will still get full strong encapsulation as compile time. When you compile your application module and no other code can reference types that are encapsulated in this module, but at runtime and also for the reflection mechanism these classes will be available to all modules and to other libraries. This feature is a trade-off that's been made to support older libraries and frameworks that make heavy use of reflection.


Is that an example of the depth that you are going through the talk?


Yes, this is one example where we run into real world problems and we'll have to use a more advanced construct of the module system to to actually make it work, and also know why it works and why this is a better solution than just exporting everything from the module.


I assume your primary audience is the Java developer?


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.


Are you going to talk about your experience with OSGi and Jigsaw?


I don't think we'll have time to dive into this while also getting into the Java 9 migration aspects. Still I do think if you're interested in that we could get into this in a Q&A at the end of the talk. I think there are very good reasons to keep using OSGi even when you're going to use Java 9. It's just a matter of how much do you need the dynamic nature of what is possible in OSGi, and if the answer is ‘I do have good use cases for that’, then definitely keep using OSGi. If you are not as much into using the dynamic nature of OSGi, and all the complexity that it brings, I do think that Java 9 with its module system offer a very compelling alternative in terms of module technology.

Speaker: Sander Mak

Fellow & Software Architect at Luminis Technologies

Sander is a Fellow at Luminis in The Netherlands, where he crafts modular and scalable software, most often on the JVM, but with a touch of TypeScript when needed. He also is a Java Champion and author of the O'Reilly book 'Java 9 Modularity' (see [](https://javamodularity)). As an avid conference speaker, Sander loves sharing knowledge, also through his blog at []( and as [Pluralsight]( instructor.

Find Sander Mak at