CODEWITHSUNDEEP
classpathjava-9java-module
HellishHeat
HellishHeat

Reputation: 2491

Java 9 Modules: Can automatic Modules result in larger (full) projects?

I guess automatic modules:

http://openjdk.java.net/projects/jigsaw/spec/sotms/#automatic-modules

means that each module of a project that requires a 3rd party jar will have to package that jar inside it's own modular jar. If that is the case couldn't a large multi-module application end up larger than its Java 8, classpath-based, counterpart? I'm thinking of all the nearly ubiquitous apache libraries and other common open source dependencies.

I get the win in the future; that all these 3rd party libraries would themselves be modularised and, therefore, only need to distribute a minimal configuration. But, in the short term, without a classpath, wouldn't there be some very bulky modular jars out there? Or am I missing something?

Upvotes: 2

Views: 511

Answers (2)

Michael Easter
Michael Easter

Reputation: 24468

Your question and comment imply that the classpath is going away: it is not.

Before addressing automatic modules, there are other concepts to understand.

In Java 9, the classpath is still around, and familiar legacy jars (i.e. non-modularized jars) will still work. However, there is also a new modulepath which contains modular jars.

Modular jars contain a module-info.class which is very explicit about (a) the modules required as dependencies and (b) which packages are exported.

A crucial point is the interaction between the classpath and the modulepath:

  • Legacy jars on the classpath don't know anything about the modulepath, so they are granted access to all modules.
  • Because the classpath is generally chaotic, it is known as the unnamed module. Because there is no name, modular jars on the modulepath can't reference legacy jars in their module-info.java.

With this much information, it would be impossible to modularize a project in a piecemeal fashion: if an application jar requires a 3rd-party library, we would have to (a) wait for the library authors to modularize it or (b) attempt to modularize it ourselves. Both are non-starters.

Enter automatic modules. They are legacy (non-modular) jars which reside on the modulepath. They act as the bridge between the classpath and the modulepath because:

  • Automatic modules are named (the mechanism is a probably a separate question), and can be referenced by modules.
  • Automatic modules are granted read access to everything in the unnamed module (i.e. legacy jars on the classpath) and all modules on the modulepath (i.e. JDK modules).

This video and this video offer illustrations.

Upvotes: 1

Nicolai Parlog
Nicolai Parlog

Reputation: 51030

I think you misunderstood how automatic modules work. Their critical property is that you can use existing, non-modular JARs, put them on the module path and have them appear as modules for compilation or at run time.

I guess automatic modules means that each module of a project that requires a 3rd party jar will have to package that jar inside it's own modular jar.

No, not at all. Quite the opposite, you reuse existing JARs.

Upvotes: 4

Related Questions