Java 9 is released in July 2017 and it contains a complete new module system. Java 9 introduces many other features as JEPL (Read Evaluate Print Loop) Jshell, factory methods for List, Set and Map, allowing private methods in interface, HTTP/2 clients etc, but these are all fairly minor changes as compared to module system. On the other hand, module system is much about design as it is about features. Modules provides new opportunities to improve the large skill structure and design of your code base. It’s a big change to both the java language, libraries and JVM. Therefore, in this blog, we are going to focus exclusively on the module system. we will discuss about
1. Strong encapsulation
2. Explicit module dependencies
5. Migrating existing code to Java 9
Module System is one of the biggest change in java ever. It’s not just a slight tweak to the language, but it affects the libraries, JDK, JVM. Everything has been changed to accommodate modules.
To answer this question, let’s first have a look at how java currently works and what is wrong with that. As we know all the external library dependencies for your application append to your Classpath when running your application. How do you know if all the dependencies are present? You won’t find out until running your application and triggering the code path that leads to loading and missing class from the missing jar in the Classpath, you don’t know upfront and that’s bad. What if you for example have multiple jars
With conflicting version of classes, the JVM will randomly pick the first one that it encounters on the Classpath. The main problem is any class in the Classpath can access other classes on the Classpath, so even though you have your application code in separate JARs, some sort of malicious third-party library goes in principal just to access your code. There is no notion of strong encapsulation. We all know about those application which just grow and grow without any clear boundaries, without any clear responsibilities in part of the applications, and everything just hangs together. People call them monolithic applications or just a big ball of mud but we all know how bad it can be to work with such an application. If you have such a monolithic application, it becomes hard to understand. New people joining the team will have a hard time understanding where to look in the code, what to do, and how to work with it. This leads to a codebase that has decreased maintainability. So how do you prevent that? Modularity is one of the answers to this question. Modularity is an ultimate agile tool.
In a high level, a module is something that has a name, think of it as an identity, and is groups related code. This code can be either encapsulated inside of the module or it can be visible to the outside world, and is self-contained. This means it contains everything it needs to perform its function, and if it does not contain everything it needs, it will have an explicit definition of what other module it needs to do its job.
You can apply a divide and conquer approach to your application, break it down, make small modules, and make your application manageable in such a way. Each of the module can choose to hide some of its implementation details and only expose the clear interfaces that are used by other modules.
In the next edition, we will look into modules in details.
Click here, for the next edition.
Senior Software Engineer
Originally published at medium.com on June 27, 2018.
Also published on Medium.