“Java 9 can do for modularity what Java 8 did for functional programming”

JAXenter: The wait is over — Java 9 has been released. What is your favorite feature and why?

Nicolai Parlog: Definitely strong encapsulation! When we’re creating modules, only public types in exported packages will be accessible to code outside the module. This allows us to share code across packages within the same module without outside code starting to use it.

Strong encapsulation adds another option to the private-public-axis and I’m convinced that exported will become as integral to our design as private and public are today.

JAXenter: Are there features you would have liked to see in Java 9 but were not included?

Nicolai Parlog: If a library changes its module name from one version to the next, it is possible to end up with an application that transitively depends on that module but references it with two different names. As it stands, the module system offers no good way to resolve such deadlocks – the application could not be launched.

For that reason, I would have liked to see an aliasing mechanism in the form of a command line option that allows users to replace one module with another. Something like --alias-module guava=com.google.guavawhere all dependencies, qualified exports, or other clauses that mention guava would be treated as if they mentioned com.google.guava instead.

I think I was pretty much the only one who thought that was a good feature, though, so it makes sense that it wasn’t implemented. And with the faster release cycle, there’s not much harm done as it could be shipped very quickly if it turns out that such deadlocks pose trouble.

JAXenter: Project Jigsaw is finally here. How do you feel about the module system?

Nicolai Parlog: I’m contractually obliged by my publisher to say I love the module system with all my heart.

Seriously, though, I think having a first-class mechanism that models relationships between artifacts and supports modularity on that level is very important. One tiny example is that stack traces now tell us which module a method belongs to. This demonstrates that the JVM finally sees JARs as more than just containers and gives them a life of their own.

Of course, other goals of the module system are much more important:

• reliable configuration (modules express dependencies)
• strong encapsulation (see earlier)
• scalable platform (create runtime images with just the modules you need)
• improved security (much code now be guarded automatically by JPMS instead of manually by security manager)
• increased JDK development speed (modularized JDK makes changes easier)

I’m convinced that these aspects will improve the quality of many projects in the Java ecosystem. Admittedly, in much less obvious ways than, for example, lambdas and streams in Java 8. Every developer could immediately see how they changed the way code was written – with the module system, effects are much more indirect.

Despite the differences between the two releases, I actually like the comparison to Java 8, though. It brought the community in contact with functional programming concepts and see how many libraries, articles, talks, and books that created — we are much better off now than we were four years ago because we have a much better grasp of those concepts. I’m hopeful that Java 9 will do the same for modularity. (I surely learned a lot about the principles of modular design.) I am excited to see how this plays out.

JAXenter: Will you get started with or without modules?

Nicolai Parlog: It all depends on the project. If it already exists and has a large code base (which was alreadymigrated to Java 9), then modularizing it will take time and in order to get good results, it should not be rushed. Instead, this opportunity should be taken to fix the project’s structure. So, in that case, I would vote for modules but move slowly.

For a new project that targets Java 9, modules would be my default. Automatic modules and the unnamed module not only allow an incremental modularization, they also enable new projects to go modular even if their dependencies don’t ship modules yet.

An important exception are publicly available libraries and frameworks. They should only ship modules if their non-modular dependencies have defined their module name in their manifest. No module should be published that requires an automatic module whose name is based on the JAR file name. Maven even warns about that.

SEE MORE: “The most substantial argument in favor of Java 9 is the modularization of JDK itself”

JAXenter: Project Jigsaw should have been a major feature of Java 8 but Oracle decided to postpone it. Instead, it became the key feature of Java 9 — was it worth the wait?

Nicolai Parlog: That’s a weird way to look at it. Would I have preferred to see the module system as it is now in Java 8? Sure!

Java 8 came out more than three years ago, though, at a time when the module system was still in the works. It took 18 more months before even a prototype could be published in late 2015. The amount of work and discussions that went into it since then are invaluable for the result we got now. Without those, the module system would have been utterly unfit for purpose, so having it in 8 was never really an option.

JAXenter: Oracle has proposed a new version numbering scheme. What’s your take on that? Do you think it’s a good idea to change it?

Nicolai Parlog: There are indeed some discussions about the version scheme, but before I get into that, I want to clarify that while this is the most controversial aspect of the recent announcements, it is also the least important. The fast release cycle, GPL-licensing OpenJDK, open-sourcing proprietary tools, and generally aligning Oracle JDK and OpenJDK are all great decisions that were met with near universal praise.

With the power plant settled, let’s turn to the bike shed: I strongly dislike the new version scheme. In the beginning, I just thought it’s odd, but the longer I think about it the less I like it. I write a weekly newsletter (published via mail and on Medium) and discussed it there at length. In summary:

• I care little about the year and much less the month a version was released in – why make unimportant information so prominent?
• year.month looks like semantic versioning (an interpretation supported be the new `Version` class) but isn’t
• if there are ever releases in other months than March or September, things get very confusing. (“So, there’s 18.3 and 18.10, but then it’s 19.3 and 19.9?”)
• the space of available versions gets “polluted” — when (not if) this scheme changes, the next version is inevitably 20-something
• every Java newcomer will have to learn about this, so they don’t go looking for nonexistent versions

I’d prefer the versioning scheme to stay very similar to what it is now. The current proposal plans a three-month feature freeze before every release – that should be sufficient time to decide whether the changes require an increase in bytecode level and major version or a minor version bump suffices. So, maybe 2018 brings us 9.1. and 9.2, but March 2019 has primitive specialization (just a hypothetical!), so we get 10.0.

SEE MORE: Life after Java 9: Will you miss the old version numbering scheme?

JAXenter: Oracle has expressed the desire to release future OpenJDK builds under the GPL. They also said there will be no technical differences between OpenJDK builds and Oracle JDK binaries. What does this mean and why should users go down the proprietary path?

Nicolai Parlog: I’m out of my depth here. All projects I ever worked on since becoming aware that there are different JDKs used Oracle’s, so I’m not sure how a switch to OpenJDK manifests itself. Generally speaking, I believe in the value and might of Free Software, though, so I applaud the move.

JAXenter: Is Java 9 as interesting for developers as Java 8?

Nicolai Parlog: I already discussed the module system’s impact, which will be nowhere as big as lambdas were on everyday coding. I’m afraid that will make developers less interested in it, but I don’t think that it’s less important for them. As I said, I think Java 9 can do for modularity what Java 8 did for functional programming.

Java 9 is more than just the module system, though, and the many other changes it brings are really cool, too! Private interface methods, collection factories, improvements to Stream and Optional APIs, multi-release JARs, … the list goes on and on.

None of them are killer features, but each solves a concrete problem that has been bugging at least some part of the Java community and I find it awesome that they get addressed. Taken together, they will noticeably improve the code we write day in, day out. And how could that not be interesting for developers?

[“Source-jaxenter”]