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

Rules

• 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