Example example_unnamed-module_access-from-automatic-module

Part of the full Java 9 Jigsaw modules example suite.

Authors

Migrated for Java Modules support documentation of Apache MavenTM in the course of the Maven Support & Care program by Gerd Aschemann (and other team members) as forked repository. Please add discussions, requirements, bugfixes, etc. to the fork instead of the original.

What is this example about?

This example is about the access to the unnamed module, i.e. to the classpath from an automatic module.

Modules in this example

  • modmain.auto - an automatic module calling classes on the classpath.

  • cpa - classes on the classpath

Example shows …​

The examples illustrates the accessibility rules access to the classpath (i.e. in the unnamed module) from automatic modules. In this example, we show that classes from an automatic module (and only them!) can access all classes from the classpath (the unnamed module) both directly and via reflection. This means that all packages from the unnamed module are implicitly exported and opened to automatic modules.

The script run.sh starts the main class from modmain.auto.

Note: No JavaDoc generation for this example.

Output

This example uses golden master testing to ensure output consistency. The expected output is compared with actual output using verify.sh.

Expected Output

Calling A.doIt(): From A, which is on the classpath
Calling A.doItPrivate() via reflection: From A, private method

Actual Output

Calling A.doIt(): From A, which is on the classpath
Calling A.doItPrivate() via reflection: From A, private method

Maven 4 Output

Calling A.doIt(): From A, which is on the classpath
Calling A.doItPrivate() via reflection: From A, private method

Maven 4 Migration

This example required a special migration approach as it contains NO explicit modules - only non-modular code.

Special Handling: No Explicit Modules

This example demonstrates an automatic module (modmain.auto) accessing classpath code (cpa). Neither has a module descriptor (module-info.java).

Problem

Maven 4’s Module Source Hierarchy requires module descriptors (module-info.java) for all source entries. This example intentionally contains only non-modular code:

  • cpa - classpath code without module-info.java

  • modmain.auto - automatic module without module-info.java

    Since there are no explicit modules, Maven has nothing to compile.

Solution

All compilation is done manually in m4/compile.sh:

  1. Manual javac invocation compiles cpa to cplib/:

    javac -d classes/cpa --release 11 $(find cpa -name "*.java")
    jar --create --file=cplib/cpa.jar -C classes/cpa .
  2. Manual javac invocation compiles modmain.auto to amlib/:

    javac -cp cplib/* -d classes/modmain.auto --release 11 \
          $(find modmain.auto -name "*.java")
    jar --create --file=amlib/modmain.auto.jar \
        -C classes/modmain.auto .
  3. Runtime uses automatic module on module-path and classpath:

    java --module-path amlib \
         -cp cplib/cpa.jar \
         -m modmain.auto/pkgmain.Main

This approach is necessary because:

  • Maven 4’s Module Source Hierarchy is designed for modular code only

  • Automatic modules must be compiled as non-modular JARs (without module-info.java)

  • Classpath code (unnamed module) must be compiled separately

  • Automatic modules CAN access classpath code (unlike explicit modules)

  • No Maven compilation is performed - pom.xml has no <sources> element