Usually, when I read about Java’s new releases, I think to myself, “Hmm, that’s nice, but why have other programming languages had that feature for decades and Java, which is by far the older language, doesn’t?”
If you are familiar with other languages, you have probably said that a lot.

However, this article IS NOT about insulting the old lady (to be honest, I really like to code with Java — but that’s another story).
This article is to discuss Java’s new feature for those developers who aren’t up on the most recent events.

Encapsulation

“A language mechanism for restricting direct access to some of the object’s components…”

That’s one of the four basic principles of object oriented programing, taught by too many lecturers in too many countries.
So we are not going to explain encapsulation; instead, we’re going to use it as a principle.

Encapsulate & Java

If you are familiar with other programming languages you probably know that when you build a new component that others may require, you must guide them through public APIs, interfaces and so on.
Well, when it comes to Java, there is always the annoying task of separate your packages into different jars.

“So what? why does it matter?”
The first question is whether it creates a sufficient encapsulation.
The answer is clearly no — it doesn’t.
How many times you saw developers who import something like sun.*?
Or the more common mistakes, like com.myworkspace.myservice.common.*?
Or even use Maven to pull a wide dependency?

Jigsaw — a very naive word for a very big mess

In order to achieve a better encapsulation of Java projects, Oracle’s Java architects gave birth to a new creature: The Module.
A module, as we already know well from other languages, is yet another layer of package access configuration.

“What’s all the buzz about?”
There are a few more things to learn about Jigsaw before you can ask that.

Structure in a nutshell

The simplest way to explain a structure is by example.
In our case, we created a new module which can be consumed by any other module, with one exception —by using a modules architecture the designer can configure which parts will be exposes and to whom.

As you can see, my module (“myServiceLogic”) requires the myWorkspaceCommon module in terms of initialization.
It exposes only a few parts of itself via the exports keyword. But, be aware of the difference between the two exports statements.
The to keyword is responsible for access restriction. For instance, only anotherServiceLogic module would be able to access the com.myworkspace.myservice.api package inside our module.
Last but not least, the opens keyword. If you are a Spring fan, you will now probably stop and say: “Hey, it’s going to break THE most popular Java framework in the whole world!” — and you would probably be right, except for the magical opens keyword. Basically, the opens keyword lets you manage which other modules have the ability to reflect the interface’s implementation — similar to what Spring does.

So, that’s it? An advanced Maven?

No, a nice distinctive thing to know about the Jigsaw project is that it isn’t a “transitive dependencies” feature, like Maven is. That means that developers can more elegantly handle the annoying dependencies problems that often crop up when using Maven.
You can enable “transitive dependencies”, however, by explicitly writing the transitivekeyword.

That’s basically all — conclusion

Now, when you are handed information about the Jigsaw project,
you’ll be equipped to dive in and determine whether it’s a good or a bad feature. Feel free to leave a note here or on your platform of choice.

Follow me on Medium or Linkedin to read more articles in the technological field.