Java modules
2 likes1,258 views
The document provides an overview of Java modules, focusing on their features such as strong encapsulation, reliable configuration, and improved performance. It includes details on migrating to Java 9+, examples of module definitions, and best practices for modularizing applications. Additionally, it addresses common issues like cyclic dependencies, unresolved platform modules, and encapsulated JDK internal APIs.
Java modules
- 1. Java Modules (why your stuff stopped working) @bbdsoftware @rorypreddy
- 2. Meet Rory • Developer in R&D team at BBD • Organizer for the Java and AWS User groups • Not related to Tyrion Lannister • Don’t do kids parties @rorypreddy
- 5. Agenda • Introduction • Modules 101 • Jlink • Demo • Migrating to Java 9+
- 10. JigSaw 2011 JSR-294 Improved Modularity Support 2006 Java 7: No JigSaw Java 8: No JigSaw JSR-376 Java Platform Module System JSR-277 Java Module System 2005 JSR-291 'OSGi 4.1' 2014
- 11. Java Platform Module System
- 12. Why Modules? • Reliable configuration + • Strong encapsulation • Leads to: • Scalable Java platform • Greater platform integrity • Improved performance -Compile + Runtime -Cleaner, more logical designs -95 Modules -sun.misc.Unsafe -Lazy loading
- 13. Modules 101 “Programming is breaking of one big impossible task into several very small possible tasks”. -Jazzwant
- 14. Define a Module - Its name - The packages it makes available publicly - The modules it depends on module name exports requires module-info.java
- 15. Some Rules • Modules are eagerly loaded • Dependency graph is built and checked on startup • Application won’t start if modules are missing • Module rules enforced when jar on module-path • Rules not enforced when same jar on class-path • Module names must be unique • Names should follow reverse domain name pattern • No support for versioning • Only one version of a module may be loaded • Tools (Maven) maybe used to load different versions of a module
- 18. Example – com.coffee com.coffee | ---com ---coffee | Coffee.class | CoffeeMaker.class | ---types Arabica.class Robusta.class
- 19. Example – com.coffee com.coffee | module-info.class | ---com ---coffee | Coffee.class | CoffeeMaker.class | ---types Arabica.class Robusta.class module com.coffee { requires java.logging; exports com.coffee; }
- 22. Example – com.app com.app | module-info.class | ---com ---app CoffeeApp.class TeaApp.class module com.app { requires com.coffee; requires com.tea; requires java.sql; requires java.logging; }
- 23. Readability And Accessibility Write code that is easy to delete, not easy to extend. - Tef, Programming is Terrible
- 24. Readability - Direct Readability com.app com.coffee com.tea java.logging java.base java.sql java.xml
- 25. Readability - Implied Readability module java.sql { requires transitive java.logging; requires transitive java.xml; exports java.sql; exports javax.sql; exports javax.transaction.xa; } String url = ...; Properties props = ...; Driver d = DriverManager.getDriver(url); Connection c = d.connect(url, props); d.getParentLogger().info("Connection acquired"); com.app com.coffee com.tea java.logging java.base java.sql java.xml
- 26. Accessibility
- 27. • Other modules can only see and use code if: 1. public 2. package is exported by target module 3. package is readable from this module • Combination referred to as "accessibility" Accessibility
- 28. package com.app; import com.coffee.Coffee; import com.coffee.CoffeeMaker; import com.coffee.types.Arabica; import … public class CoffeeApp {… The type com.coffee.types.Arabica is not accessible module com.app { requires com.coffee; requires com.tea; requires com.coffee.types; } com.coffee.types cannot be resolved to a module Accessibility
- 29. Unnamed And Automatic Modules “Programs must be written for people to read, and only incidentally for machines to execute”. -Harold Abelson
- 30. Unnamed Module -Used for -Java 8 and older versions -Small or temporary applications - Added via the class path - The unnamed module reads code in any other module - The unnamed module exports all of its packages. >jdeps minecraft1.12.jar Warning: split package: javax.annotationjrt:/java.xml.ws.annotation server.jar com.google.gson-> java.sql <unnamed> -> com.google.common.base ….
- 31. Automatic Modules • JAR from the class path that has been put in the module path. • Don’t wait for third party libraries to become modularized. • Becomes a named module with • Automatic-Module-Name in Manifest.mf • Otherwise, a name is derived from the JAR filename • Reads every other named module. • Exports all of its packages. • It guarantees direct and implied readability to all other modules.
- 32. Summary of Readability Module Type Origin Export Packages Read Modules Named Platform Provided by platform Explicitly NamedApplication All JARS containing module-info on the module path Explicitly • Platform • Application • Automatic • Unnamed Automatic All JARs without module-info but on module path All • Platform • Application • Automatic • Unnamed Unnamed Classpath All • Platform • Automatic • Application
- 33. Cloud-native is an approachto building and running applicationsthat exploits the advantages of the cloud computing delivery model. Source: https://pivotal.io/cloud-native jlink
- 34. jlink jlink java.sql java.xml java.base java.logging com.app Modular run-time image …confbin jmods
- 35. jlink $ jlink --module-path $JDKMODS:$MYMODS --add-modules com.app –-output myimage $ myimage/bin/java –-list-modules com.app [email protected] [email protected] java.base@10 java.sql@10 java.logging@10 27 MBs vs 226 MBs
- 36. Demo http://github.com/roryp/spring-maven-modules
- 37. Migrating to Java 9
- 38. Migrating to Java 9+ module java.base module java.sql module java.logging module java.xml myapp.jar mylib.jar lib1.jar otherapp.jar lib2.jar Bottom Up Library Migration Top Down App MigrationYour app Libraries and Third party apps JDK
- 39. module java.base module java.sql module java.logging module java.xml module myapp module mylib lib1.jar otherapp.jar lib2.jar Top Down App MigrationYour app Libraries and Third party apps JDK AUTOMATIC MODULE Migrating to Java 9+ (Migrating your application and using “not migrated” libraries that are still residing on the classpath)
- 40. Bottom Up Library Migration module java.base module java.sql module java.logging module java.xml myapp.jar mylib.jar module lib1 module otherapp module lib2 Your app Libraries and Third party apps JDK UNNAMED MODULE Migrating to Java 9+ (Migrating the libraries first and using migrated modularized libraries while your app is still on the class path)
- 41. HOW TO MODULARIZE • Introduce a module-info.java file for each module • A module-info.java file can be: • Created manually by the developers • Automatically generated using the JDeps tool with the option --generate-module-info
- 43. MODULARIZE - Issues 1) Encapsulated JDK internal APIs 2) Not resolved modules 3) Cyclic dependencies 4) Split packages
- 44. ENCAPSULATED JDK INTERNAL API • Most of the internal JDK APIs are inaccessible in Java 9 • Trying to access them causes a compilation error • Internal APIs are in the sun.* package are part of the jdk.unsupported module . Not java.base • The module jdk.unsupported provides: • sun.misc.Unsafe, • sun.reflect.Reflection, • …
- 45. batik-codec.jar -> JDK removed internal API JDK Internal API Suggested Replacement ---------------- --------------------- com.sun.image.codec.jpeg.JPEGCodec Use javax.imageio @since 1.4 com.sun.image.codec.jpeg.JPEGDecodeParam Use javax.imageio @since 1.4 ENCAPSULATED JDK INTERNAL APIS • JDeps can report internal dependencies $ jdeps --jdk-internals 'lib/batik/batik-codec.jar'
- 46. Solve the problem of JDK internal APIs: • Replace each of your JDK internal APIs calls with supported APIs. OR • Break the encapsulation with --add-exports --add-exports java.base/sun.net=ALL-UNNAMED
- 47. NOT RESOLVED PLATFORM MODULES • From jdk-9+118 running code on the class path , these types will not be visible by default: • java.activation • java.annotations.common • java.corba • java.transaction • java.xml.bind • java.xml.ws
- 48. NOT RESOLVED PLATFORM MODULES • Make that module available for compilationwith --add-modules: >Javac --add-modules java.xml.bind • And again for execution: >java --add-modules java.xml.bind
- 49. CYCLIC DEPENDENCIES • Forbidden at compile-time (between modules) • JPMS does not allow cycles in the “requires” clauses • JPMS allows cycles in the “reads” relation of run-time modules module A { requires B; } module B { requires A; } • One solution is to merge the JARs into a single module
- 50. SPLIT PACKAGES • Modules that contain packages having the same name must not interfere with each other • Solution for JAR files: 1. Create a single JAR file out of the two JAR files 2. Rename one of the package • Solution for modules: 1. Create a single module out of two or more modules 2. Create a third module 3. Remove the package dependencies
- 51. Looking Ahead
- 53. Do not add a module-info.java module declaration until: 1. All of your runtime dependencies have been modularised • (either as a full module or with a MANIFEST.MF entry) 2. All those modularised dependencies have been released to Maven Central 3. Your library depends on the updated versions If you can't meet these 3 criteria • Add a MANIFEST.MF entry following the agreed module naming conventions Module Hell If everyone does this we stand a reasonable chance of avoiding Module Hell