Download to read offline
Java modulesystem
- 1. Java Module System forMortals MahmoudAnouti / Marc Kassis
- 2. Motivation • Makes iteasier for developers to construct and maintain libraries and large applications • Improve the security and maintainability of Java SE Platform Implementations in general, and the JDK in particular
- 3. Motivation • Enable improvedapplication performance • Enable the Java SE Platform, and the JDK, to scale down for use in small computing devices and dense cloud deployments.
- 4. Goals of theModule System Reliable configuration: solve classpath issues Strong encapsulation: ability to define public APIs for a component Scalable Java SE: ability to assemble custom runtime image Encapsulate internal APIs (sun.* classes) Improved performance
- 5. What is amodule? A named, self-describing set of program components consisting of code (Java classes, interfaces) and data (resources / config files)
- 6. What is amodule? classes < packages < modules
- 7. Module declaration module-info.java: 1. Modulename 2. Required modules (dependencies) 3. Exported packages module com.example.myapp { requires com.example.lib; exports com.example.foo; exports com.example.foo.bar; } (1) (2) (3)
- 8. Module declaration • Dependencies:A module definition can require other modules to compile and run. • Exports: A module can export one or more of its packages for use by other modules. Code that accesses API in non-exported packages will fail (both compile and runtime).
- 9. Module declaration • Resourcesin a module are accessible only by code within that module. • Services: a module can declare that it uses a service interface whose implementations may be provided by other modules. • Resolution:The module system resolves all transitive dependencies required by an initial module result is a configuration
- 10. module-info.java keywords module A{ requirestransitive B; exports com.example to D; opens com.example.beans; opens com.example.private to E; }
- 11. Services module com.example.serviceapi { exportscom.example.myservice; } module com.example.serviceimpl { requires com.example.serviceapi; provides com.example.myservice.MyServiceInterface with com.example.impl.MyServiceImpl; }
- 12. Services module com.example.client { requirescom.example.serviceapi; uses com.example.myservice.MyServiceInterface; }
- 13.
- 14. Module artifacts • Amodule can be packaged into a modularJAR file: META-INF/ META-INF/MANIFEST.MF module-info.class com/example/foo/Main.class com/example/foo/bar/Bar.class ...
- 15.
- 16. Platform modules module java.base{ exports java.io; exports java.lang; exports java.lang.annotation; exports java.lang.invoke; exports java.lang.module; exports java.lang.ref; exports java.lang.reflect; exports java.math; exports java.net; exports java.util; ... }
- 17. Module path • Themodule system resolves modules by locating them in a module path: sequence of elements, where each element is either: a module artifact (e.g. modular JAR), or a directory containing module artifacts Classpath is still there!
- 18.
- 19. Reliable configuration module com.example.myapp{ requires com.example.lib; requires org.apache.commons.io; } module com.example.lib { requires java.sql; exports com.example.utils; }
- 20.
- 21. Reliable configuration •Every dependencyis fulfilled by precisely one other module •The module graph is acyclic •Every module reads at most one module defining a given package •Modules defining identically-named packages do not interfere with each other.
- 22. requires transitive module java.sql{ requires transitive java.logging; requires transitive java.xml; exports java.sql; exports javax.sql; exports javax.transaction.xa; }
- 23.
- 24. Strong encapsulation If twotypes App and Util are defined in different modules, and Util is public, then code in App can access Util iff: 1. App’s module requires (i.e. reads) Util’s module, and 2. Util’s module exports Util’s package. public is no longer public!
- 25. Migrating to modularcode • An existing classpath app running on Java 8 will continue to run on Java 9, so long as it only uses standard, non-deprecated Java SE APIs. • Code that does not belong to a defined module, belongs to the unnamed module.
- 26. The unnamed module •Contains types that exist on the classpath • Reads (i.e. depends) all other modules, including platform modules • Exports all packages, ... • A explicit named module cannot read the unnamed module
- 27.
- 28. Bottom-up migration com.example.app com.example.orm java.sql java.basejava.logging com.example.utils
- 29. Bottom-up migration com.example.app java.sql java.basejava.logging com.example.utils com.example.orm
- 30. Bottom-up migration java.sql java.basejava.logging com.example.utils com.example.orm com.example.app
- 31.
- 32.
- 33. Top-down migration java.sql java.basejava.logging com.example.utils com.example.orm com.example.app Automatic modules
- 34. Automatic modules • Itsname is derived from Automatic-Module-Name in MANIFEST.MF, or from the JAR file name • Non-modular JAR that gets added on the module path • Exports all its packages • Reads all other modules • Reads the unnamed module
- 35.
Editor's Notes
- #15 Mention JMOD artifact format