1

Prior to Java 9, I had assumed that packages were a way to promote/enforce modularization of code and to solve the namespacing problem. Packages actually do a really poor problem of solving the latter (com.popkernel.myproject.Employee myEmployee = new com.popkernel.myproject.Employee();, ugh) so I primarily focused on the former benefit.

And while packages do a very poor job at enforcing modularity, I've found them quite effective at promoting modularity. "What package does this class belong in?" has always been an illuminating question, and I appreciate that Java forces me to ask myself it.

But now Java 9 modules are here and they enforce the modularity problem better than packages. In fact, you could compose a new project entirely out of modules where each module wraps a single package.

Of course, modules are a LOT of extra boilerplate compared to packages, not to mention the quirk that unlike packages, it is impossible to tell what module a class belongs to just by examining its .java file.

So going forward my plan for using packages and modules together is: as I'm writing code, group related concepts into packages. Then, if I decide I want to distribute the code I'm working on, formalize it into a module.

Is that a sane way to utilize those concepts in tandem?

PopKernel
  • 4,110
  • 5
  • 29
  • 51
  • I don't understand how packaging does a poor job solving the namespacing problem. I think they tend to do a rather good job. – erip Oct 04 '17 at 02:45
  • The problem is packages should be hierarchical. For example, I should be able to refer to com.foo.popkernel.myproject.Bar by writing import com.foo.popkernel.* and then I could use myproject.Bar as the type name. – PopKernel Oct 04 '17 at 02:48

1 Answers1

1

Is that a sane way to utilize those concepts in tandem?

Yes, kind of. Though there are other benefits that you can gain from modularising your code such as Reliable configuration, Strong encapsulation, Increased Readability etc.

So going forward my plan for using packages and modules together is: as I'm writing code, group related concepts into packages. Then, if I decide I want to distribute the code I'm working on, formalize it into a module.

A quick question you can ask yourself is that while you would be using modules, and as you would group related concepts into packages, eventually how do you group related packages then?

The answer that could match up to the reason is the introduction of a new kind of Java program component - Modules

A module is a named, self-describing collection of code and data. Its code is organized as a set of packages containing types, i.e., Java classes and interfaces; its data includes resources and other kinds of static information.

Until now such collections were primarily targeted as JAR files, that were distributed to be consumed as dependencies/libraries within other, but they are becoming legacy formats and differ quite a bit with modules. In one of my recent answers to Java 9 - What is the difference between "Modules" and "JAR" files? I have tried to detail the differences.

Naman
  • 27,789
  • 26
  • 218
  • 353