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