We've looked at steps and strategies to follow when migrating applications to the Java modules. How about libraries? Let's say you are the maintainer of an open source library that is used by many people. Or, perhaps, you maintain a library that's used by multiple teams in your organization. How would you migrate such a code base? Wouldn't that require you to follow the same steps we've covered to migrate applications? Well, mostly yes. However, there are certain things you need to do differently with libraries. This section covers those details.

What's perhaps the biggest difference with libraries is that you no longer work in the context of an application. A library could be used by multiple applications. These applications could be using multiple versions of Java. How could you create a single library JAR that could work for all those cases? Thankfully, there are some features in the platform that make this easier.

Before we get into those specific problems, let's look at what it takes to migrate library code to use Java 9 modules. Here are some high-level steps you need to follow as a library author:

1. Eliminate the JDK internal API usage: This is no different from what we did for applications. We need to make sure the library is a good Java 9 citizen. Calls to JDK internals or deprecated APIs are a no-no. Refactor your code to avoid the calls or use a replacement that our friendly jdeps tool with the --jdk-internals option suggests.
2. Eliminate any split packages: We've looked at how split packages cause problems with automatic modules. You'll need to make sure your JARs do not contain packages that could potentially exist in other JARs in your organization. If other teams own libraries whose packages conflict with yours, you'll need to work with them to streamline the package names
3. Identify a name for your core library module: As with any module, you need to come up with a name for the library. This is not that big of a deal when working with libraries that are used only in your organization. However, it's a much more important step when dealing with open source modules. Like we've covered in Chapter 2, Creating Your First Java Module, module names can follow reverse domain name convention. You can opt to go with a shorter name for strictly in-house libraries to ease readability and communication, because name conflicts are less likely in such cases.

4. Start refactoring and converting your code into modules: This involves moving your code into module root folders, adding module descriptors, and defining the requires and exports definitions for your modules. Be careful about any types that you encapsulate. If there are consumers of your library using those types, they'll not be able to use them anymore, unless they add the --add-exports overrides.

As with application migration, I highly recommend that you survey your library code and come up with a high-level module diagram that outlines the relationships between modules before you start digging into the code and moving files around. It will save you a lot of time and work!

5. Add transitive dependencies or wrap around dependency leakage: There's a chance that your library code depends on other libraries. They may be other in-house libraries or open source JARs. These libraries may not be migrated to Java 9 yet, and we have the same problem we did for application dependencies. Here, again, you'll need to use automatic modules for the JARs that your library depends on. If using your APIs requires access to those libraries, it's a good idea to add require transitive on those libraries in your module definition. If possible, wrap around those types so that the code consuming your library doesn't have to be aware of this dependency.