modules.md

Overview

1. Java 9+ modules

Key points

1. Modules can be annoying because some popular 3rd party libs haven't adopted them (eg. Netty, Google, ...).
2. Use a bottom-up approach
   1. Start with simple relatively independent (gradle) modules
   2. Unnamed/automatic modules can access modular code, but not the inverse
3. a module contains one or more packages
4. a module exports packages
5. a module depends on other modules via requires
6. (unlike packages) modules have no hierarchy
   1. names are just names (similar to golang packages)
7. --add-exports: only public members accessible
8. --add-opens:
   1. even private members accessible thru reflection (eg. Field::setAccessible(true))
   2. Runtime concern, not compile time
9. --patch-module: merges all classes from an artifact into a module (helps fix split packages)

New abilities

1. Hiding packages from other modules
2. Fine grained control over access at runtime (Reflection too)
3. Granular JVM
4. Faster startup

Gotchas

Split packages

1. eg. jsr305, replace with jetbrains annotations package
2. Sometimes split package issues manifest with unrelated error messages
3. --patch-module name.of.module=path/to/my.jar might help
   1. also requires an --add-modules step
4. --upgrade-module-path might help

Google libs tend not to have module-info.java

1. eg. [google.cloud.storage](https://mvnrepository.com/artifact/com.google.cloud/google-cloud-storage)

TODO:

• TODO: "legacy" jars
• TODO: classpath
• TODO: jdeps
• TODO: gradle
• TODO: modulepath
• TODO: naming (chars, length, ...)
• TODO: unused required (Intellij)
• TODO: open
• TODO: opens
• TODO: transitive

Other Resources

1. TODO