INTERVIEW

The Java Jigsaw Puzzle

Six questions (+1 bonus question) for Nicolai Parlog, author of The Java Module System

Nicolai Parlog is a developer, author, speaker, and trainer. His home is codefx.org.

__________________________________________________________________

You can also get The Java Module System for 39% off by entering intparlog into the discount code box at checkout at manning.com.
__________________________________________________________________

What is Java’s Project Jigsaw?

Project Jigsaw was tasked with cutting the monolithic JDK (Java Development Kit) into modular pieces and developing a mechanism that could operate on these pieces in a helpful manner; the result is the Java Module System. The module system is a big thing, but at its core it’s pretty simple: Bundles of code (JMOD files for the JDK, JAR files for our projects) can be given a name, a list of dependencies, and a clearly defined API. The module system understands these pieces of information and uses them to make code bases, particularly larger ones, more maintainable. For the first time, the JVM (Java Virtual Machine) doesn’t treat JARs (Java ARchives) as feckless containers, but as meaningful entities!

Without modules, the class loader can’t tell you where a class comes from, the JVM won’t notice missing dependencies until it’s too late, and there is no effective encapsulation of project internals. With modules, this–and more–changes. Two important features are reliable configuration, where the module system makes sure at launch time that all dependencies are present, and strong encapsulation, whereby it is assured that only a JAR’s public API is used and internals are safe, even from reflection. The latter effectively gives us a new visibility modifier between default package visibility and public. Finally, an API can be “public within the JAR, but not beyond.” We can now also express in code which packages were designed for public consumption and which are implementation details. This was not possible before, and all too often, particularly in larger projects, code is used way beyond its intended use, leading to maintainability problems that could have been avoided by clearly communicating an API’s operational area.

Modules started making an appearance in Java 9. What’s different about the module system in Java 11?

Yes, modules and the module system were introduced in Java 9. The module system itself hasn’t changed since then. The only module-related change was the removal of Java EE APIs in Java 11. JDK downloads historically have contained a few Java EE APIs even though they were never standardized for Java SE. Java 9 placed those APIs in six modules that were not resolved by default and deprecated for removal. Java 11 made good on that promise and removed them.

Was Java a bit late to modules? Does Java handle modules differently compared to how other languages deal with them?

I really can’t say anything reliable about other module systems. But even comparing Java to itself in a parallel universe, yes, it was late to modules. Part of the module system’s complexity comes from the necessity to make it work in an ecosystem that’s over twenty years old with billions of lines of code. If Java had started with a module system or got one in the early 2000s when it was first discussed, many things would have been much easier.

It’s almost funny how the module system’s adoption mirrors its development. Most people agree that it’s necessary, but it’s not really fun, so it gets put off, which only makes the work harder.

I know you wrote a whole book on this, but could you briefly summarize the advantages of programming with modules?

I already explained the benefits of strong encapsulation. Together with features like reliable configuration (the module system checks whether all project dependencies are present), a scalable platform (we can create a runtime image with just the JDK modules we need and even one that includes an entire application) and improved security and maintainability (thanks to clearly defined module boundaries) the module system delivers value in a few different ways.

They’re not exactly revolutionary, though, and they’re way less fun than lambdas or text blocks because they’re less a shiny new tool and more a safety belt. Again, everybody agrees you need one, but few people are outright enthusiastic about them.

Another important “safety” aspect is not technical, though, it’s behavioral. When you create modules, you have a module-info.java file in each subproject, describing each module. These files easily become the most important source files in the project: In just a few lines they describe your system’s parts and how they interact. Whenever you change your system’s structure, you need to change these files, which makes them a great focal point when reviewing code. They’re also a great place for comments, stuff like: what does the module do, why is this export qualified, what’s up with the optional dependency? Module declarations give you a default location to document and review your system’s structure, so you should take good care of them!

You’ve got your fingers in a lot of pies, as a developer, speaker, blogger, instructor, and consultant, trainer… Do you also have a day job?

I actually don’t have a day job any more. I freelance as a Java developer and recently as a conference organizer for Accento. I also do trainings and write the occasional article. But I spend almost half of my time learning about all the new things that go into Java and putting them into blog posts, newsletters, videos, live-coding streams, and talks.

What was your biggest challenge in making the transition from writing blogs to writing a book?

My biggest challenge when writing is the empty editor. That idea in my head, but nothing but a dark pane and a blinking cursor before my eyes, always gives me the chills. I tend to mentally block and not get anything done. I start procrastinating (Twitter, video games, news, Netflix…). That challenge is pretty much the same when writing a book, where every new chapter is a blank slate, or blog posts. But with a book it delays the entire product, making the entire process way more mentally taxing than banging out a blog post.

***BONUS QUESTION***

Would you talk a bit about your advocacy work for digital rights and open source?

I’d love to! To keep a (somewhat) level playing field between competitors, large and small, between companies and customers, and between the states and their citizens, it is crucial that this sphere remains easy to access and protects fundamental freedoms. Big tech like Google, Facebook, Amazon, and the like collect extensive amounts of data about everyone, which undermines central human rights to privacy–so far mostly to show ads and train AI, but other organizations with much more direct impact on our well-being–governments and health insurance companies, for example–can’t wait to get their hands on the data.

Generally speaking, there are many areas of our lives where underrepresented groups have a harder time competing on par because they face more resistance, and these biases are reflected in the data that our observable behavior creates–from credit scores to criminality rates. If AI is trained with that data, our societal biases get baked into their behavior and they will reproduce it. It’s not like algorithms have some magic property that makes them just and fair; they can be just as misogynist, racist, or otherwise oppressive as societies can be. So even if societies are mostly fair, if you take a small disadvantage and perpetuate it in algorithms that may soon rule much of our lives, the overall effect will still be very large.

There are lots of other concerns, but long story short, there are many aspects of our lives where fairness and fundamental human rights are in danger in the digital sphere–often just a little bit, but multiplied a few billion times across the globe, these little bits matter a lot. We as developers are better equipped to understand the threats and I see it as our duty to communicate it to our families, friends, and communities and do our part in fighting back. Whether that’s open-source development, digital-rights advocacy, or monetary support is up to the individual, but shaking your head at the news is not enough.

Originally published at https://freecontent.manning.com.