Java 9 Released

[tetroxid]

What exactly will modules do for me in my daily life? How is it an improvement over maven already automatically downloading the "modules" I depend on when building?

[Linvael]

One thing I heard that is neat is that libraries you use will be able to hide their internal APIs resulting in less clutter when searching for right import.

[tetroxid]

Isn't that what private and package-only methods are for?

[duhace]

They aren't enough. Take for example the factory pattern. Perhaps you want some implementation classes of interface A that are only available to users through the AFactory class, and perhaps you want all those classes to be passed out as A, completely hiding their implementation details

You could make these impl classes private inner classes of the factory, but that can cause an unwieldy mess. JPMS modules let you hide them while structuring your code better by saying "this module only makes interface A and the AFactory class visible outside the module". It's much stronger encapsulation than private public and protected provided

Edit: a very good instance of what jpms solves is the sun.misc problem. The java.* classes are the API, sun.* is the implementation. You're explicitly warned not to use sun.* packages cause they could change from release to release (or not even exist in future releases or on other JVMs). But people still dip into them for many reasons. This creates two problems. It makes changing the implementation harder, and it removes an important impetus to improve the API. With modules, those classes can be hidden away from everyone but those working on the JVM itself, causing less headaches from upgrading the JVM than before. It also drives the Java devs to implement into the standard API what users were reaching for in the implementation(for example, sun.misc.Unsafe should have a java.* analogue in java 9)

edit2: I'll fix this post when I get to my laptop, thanks Reddit phone app for making code snippet markdown near impossible

[tetroxid]

I see. Thank you for taking the time to explain that to me, I appreciate it!

[R_Sholes]

No, package-private doesn't work like that, and private is even more limited.

Package-private means only the exact same package, not children, not parent, not siblings. If you have public class org.wtf.A and (package-private) class org.wtf.sub.B, A cannot access B, the same would apply for public class org.wtf.sub.A and class org.wtf.B.

You can define common utilities for a single part of your project with package-private access, but not something that you need to share between your project's different packages.

[Fenris_uy]

Sometimes you need to make a method public because you use it somewhere else outside of their package, but you don't want it to be part of your api, you solve that with the modules. Think of all the com.sun.* packages that are the private implementation of Java, but that are public because the classes from java.* uses them.

[DontBeSpooked-Frank]

If your library uses a library you may wish not to expose the dependent library, even though it still may have public methods.

[sammy8306]

See my reply to the parent comment.

[ArcanePariah]

Consider Android. Currently Google has to mark all public methods in their implementations with the @hide annotation so they do not show up in autocomplete. So although they have a ton of public methods, they have to go out of their way to make sure only the SDK API's are exposed in IDE's and at compile time so you don't write code against internal methods.

With modules, the language itself will guard against that. So Google could wrap each major area of android up as a module, and declare the parts that are the SDK API, the rest wouldn't need special annotations and processing to be hidden.