In the previous chapter, we looked at what it takes to start with a pre-Java 9 code base and have it compile or run with minimal changes in the new Java 9 platform. We also looked at some problems you could face with your legacy code and how to solve them.
If you are working on a code base that you expect to make many changes or enhancements to, then you'll want to do more than just run it in Java 9. You'll want to take advantage of the modularity features that Java 9 provides. Of course, you shouldn't always blindly rewrite your application to use modules just because you can! The advantages of modularity--strong encapsulation and reliable configuration--are the most useful in applications where there is a large code base with clear boundaries and multiple teams working on it. In this chapter, we'll take a look at how you can use those new modularity features and gradually introduce them to your pre-Java 9 codebase.
These are the topics we'll be covering in this chapter:
- Migration strategy for codebases
- Automatic modules
- Library migration
- Multi-release JARs
We'll be working on the shopping bag example that we've looked at in the previous chapter. We've got it compiling and running in the Java 9 platform. We'll now be adding modularity features to the code.
Now, how do you go about doing something like that? In the case of a small application, like the example code we are looking at, it is trivial to make a complete change across the application--you can split a small codebase into modules based on the roles that different types in your code performs. And then wrap the individual modules in modules with the right module definitions. Easy!
Unfortunately, most real-world applications are much larger and more complex. Thus, they cannot be modularized with a big bang approach. You'll have to gradually chunk away at it, moving portions of the application into modules. How would this work in an application where a portion of the code is modularized while the rest isn't? In addition, most applications, especially enterprise Java applications, use some kind of a framework or library to handle application infrastructure. What does Java 9 migration mean in those cases? Would the libraries need to be rewritten to use modules as well? Could you modularize your application while the libraries are not yet modularized? Before we answer these questions, let's first understand what the migration goal is. What are we trying to achieve?