[2019 oracle code one] modules

Java Modules: Why and How?

Speaker: Venkat  Subramaniam @venkat_s

For more blog posts, see The Oracle Code One table of contents

Why modules?

  • Modules designed to make the JDK itself modular
  • It’s like bringing these 70 suitcases with you on vacation in case you need something.
  • Better security. Can’t create another jar with same package and access package private.
  • Easier to make new things secure
  • In law mode – The build team drops a few jars until you call that functionality and get class not found. With modules, runs in mother mode. Pre-check what need. Fail fast
  • Reuse release equivalency principle – reuse the whole of what released. USPS gives partial packages. Don’t want that. You export packages but receive/require module. This is a handshake. Both have to extend hands. One must export and the other must require.

Module example

  • Showed compiling, jarring up and running the java command
  • -p modulePath
  • -m modName/my.package.MyClass
  • jar -f myJar.jar -d – tells you about jar file metadata. Will show derived info for old modules that lack formal metadata

Module types

  • Unnamed module – exactly one. Contains everything you dump in the classpath. Whether it is a module jar or not
  • Automatic module – legacy jars on module path
  • Explicitly named modules – jars with module descriptor on module path

Module info

  • exports – package that other code on module path should be able to access.
  • Public is no longer public. Public without exports is not available
  • requires – want to use module
  • requires transitive – never use for third party library. Only use when refactoring a ball of mud into pieces


  • Any jar running in the classpath is called an unnamed module
  • Any transitional jar running in the module path is called an automatic module
  • Any jar with a module descriptor running in t classpath is a n unnamed module
  • Any jar with a module descriptor running in the modulepath is an explicitly nmaed module
  • Modules can’t share packages
  • Unnamed modules can talk to other unnamed modules
  • Automatic modules can talk to other automatic modules
  • Automatic modules can talk to unnamed module
  • Unnamed modules cannot talk to automatic module (Get class not found across module path/classpath when can’t access because doesn’t even look there)
  • An explicit named module can talk to other explicit named modules
  • An explicit named module can talk to automatic modules
  • An explicit named modules cannot talk to unnamed module
  • An explicit named module has to require any modules it needs incudling automatic modules (so please give a decent name)
  • An explicit named module exports only what it specifically exports
  • An unnamed module automatically exports all its packages

Migration path

  • Run all in classpath in old Java
  • Run all in classpath in latest Java
  • Fix any errors
  • Run them all in module path
    Give names for automatic modules
  • COnvert from top to bottom to explict modules

My take

I like Venkat’s laptop stand so he can type and use the computer. I also enjoyed seeing his enthusiasm. I’ve been writing about modules lately so seeing it explained a different way is useful. The demos are good. The list of rules is a good reference (or review) as well

Leave a Reply

Your email address will not be published. Required fields are marked *