We've made several enhancements to the address book application to make use of some platform APIs and learnt some lessons on how to find and use platform modules, as well as how to handle some tricky scenarios that showed up along the way. Here's what we have done so far:

• We used the java.logging module to add logging functionality to the packt.addressbook module.
• We used the java.xml module and created a new custom module that reads and parses an XML file to return a list of model objects.
• We encountered two problems--shared code and dependency leakage and we implemented a strategy to get around those problems.
• We used the JavaFX modules to build a UI for the address book. We created a new module that leveraged our existing contact and sort modules to build this UI. We learnt about the impact of modularity on reflection. We got around the problem by just exporting the class that needed access by the framework, although we'll be learning a better way to do this in the next chapter.

One additional point that I want to highlight is how, in this chapter, we were able to leverage the modules that we'd already built to create a new custom GUI module. Notice that we didn't have to mess around with existing code and pile up logic and functionality on them with if clauses. We were easily able to create a new module for GUI, and thanks to the other core functionality being separate modules, we were just able to use them as building blocks to create a brand new module with all the functionality we needed. The packt.contact and packt.sortutil aren't aware of where they are being used, so they technically don't care!

In the next chapter, we'll look at a few more tricks that the Java module system has up its sleeve! We'll also deep-dive into concepts related to readability and gain an understanding of more powerful ways to make different modules accessible to one another.