Vignesh Ramesh gives an overview of Java modules in Java 9. Modules allow for strong encapsulation by only exporting certain packages. This addresses issues in Java 8 where all packages were effectively public. The module system solves problems like weak encapsulation and jar hell. Key aspects include module descriptors, exports, requires, and the new jlink tool for creating custom runtime images.
2. About Me
• I am Vignesh . Insanely passionate full stack developer with high
proficiency in Java, Scala, Node.js, JavaScript.
Github : https://github.com/vickii
Linkedin : https://www.linkedin.com/in/vickyramesh/
StackOverFlow :
3. What is a Module ?
• Module is a collection of packages designed for reuse.
• Modular JAR is a regular JAR with a module descriptor[a module-
info.class] in its root folder.
• A key motivation of the module system is strong encapsulation
4. Why Modules?
Whenever a new JVM is started the bootstrap classloader is
responsible to load key Java classes (from java.lang package) and other
runtime classes to the memory first.
rt.jar is about 64mb in jdk-8. Do we need all the classes runtime
classes?
Depends on the Application right?
5. Why modules?
There is no way to reuse a behavior defined inside a package in another
package unless and until it is public . But public is too open .
[Developers started using JDK internals which was not supposed to be
used ex: sun.misc.Unsafe Using it, you can create an instance of a class
without invoking it’s constructor code, initialization code, various JVM
security checks and all other low level things. Even if class has private
constructor, then also you can use this method to create new
instance.].
JDk8 contains about 218 packages. This weakens encapsulation. This
was one of the main reason why JDK itself was modularized.
6. Maven modules vs JPMS
MAVEN MODULES JPMS
Build Time only. Everything is on
classpath during runtime where no
boundaries are available
Compile time, Run Time
Sub-project Packages
7. Module vs JAR
• A module can decide which classes and interfaces to export to other
modules that require it. A Jar has no such encapsulation mechanism.
• The name is of a JAR can be changed. As long as the JVM classloader
finds the needed class on the classpath (which can be composed of a
single JAR, multiple JARs, or a mix between directories or JARs), the
name of the JAR file can be anything. However, the name of a module
can be explicitly referenced in the declaration of other modules, and
such the name defines it and cannot be changed freely.
9. Accessibility
Accessibility prior to JAVA 9 Accessibility on java9
public but only to specific modules
public only within a modules
public public to everyone
protected protected
<package> private <package> private
10. Public is no more an golden switch
• Public no longer means accessible if the package is not exported by
the parent module[module which has that class]
• This is the point of controversy in Java9 due to which many libraries
like Glassfish was failing on JDK-9 because they were using jdk
internals which are no longer exported.
Temporary access : ‘--illegal-access=permit’
Proposal: Allow illegal reflective access by default in JDK 9
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-
May/012673.html
11.
12. JDEPS : Dependency Analyzer
• JDeps is a "Java [static] class dependency analyzer" that is useful
for quickly identifying "static dependencies of applications and
libraries.
• The input can be a path name to a .class file or a JAR File.
• Example : jdeps dependency list for junit-jar. –s option is for summary
13. Types of Modules In Java
• Named Modules
• Unnamed Module
• Automatic Modules
14. Named Module
• Contain a module-info.java
• Loaded from the module path.
• Only their exported packages are accessible and they can only require
and thus read other named modules (which excludes the unnamed
module).
15. Automatic Modules
• Does not contain a module-info.java.
• Loaded from the module path.
• There name is derived from the jar file name by default.
• Explicit naming is recommended by setting the Automatic-Module-
Name variable in MANIFEST.MF.
• They export all packages and requires all modules, including
automatic one’s.
• Automatic, or automatically named, modules are JARs without a
module-info.java that were loaded from the module path. Their name
is derived from the JAR file name, they export every package and read
any module, including other automatic ones.
16. Un-Named Modules
• Does not contain a module-info.java
• Loaded from classpath.
• Requires all named modules
• All classes within the unnamed module can read all other module
(named or unnamed) without any explicit declaration of any kind.
That also means that older classes (written prior to Java 9) can read
all modules defined by the new Module system
• Exports all packages
• The packages exported by unnamed module can only be read by
another unnamed module. It is not possible that a named module can
read (requires) the unnamed module
17. Creating an Module
• In Java 9, you need to have a specific file name by convention in order
to define modules with a specific filename. That filename should be
called module-info.java.
Example:
module modulename{}
• Don’t worry module is not a keyword in java
• If your module name is com.example.myapp then the module.info
should be placed at src/com.example.myapp/module-info.java path
18. Module-info.java
Module com.example.myapp{
exports com.example.myapp.utils;
requires java.base;
}
• This module[com.example.myapp] only needs types from the base
module 'java.base’ because every Java module needs 'java.base', it is
not necessary to explicitly require it.
• This module[com.example.myapp] only exports the package
com.example.myapp.utils for public use to other modules. Classes in
other packages cannot be accessed by other modules.
21. Implied Readability
• Let’s look at the java.sql module. It exposes the interface Driver,
which returns a Logger via its public
method getParentLogger(). Logger belongs to java.logging. Because
of that, java.sql requires transitive java.logging, so any module using
Java’s SQL features can also access the logging API.
JDK Example:
module java.sql {
requires transitive java.logging;
requires java.xml;
}
22. JLINK : The Java Linker
• Jlink is Java’s new command line tool through which we can create
our own customized JRE. It is an best illustration of the concept just
enough runtime.
• Usually, we run our program using the default JRE, but in case if you
want to create your own small customized JRE, then you can go
with the jlink concept.
• This feature is very useful in the era of microservices and
containerization
• jlink takes into account transitive dependencies from the top modules
and generates a custom Java image.
23. JLINK : Uses
class App {
public static void main(String[]args) {
System.out.prinltn("Hello World");
}
}
To execute this small “hello world” application, we require the
following .class files:
• App.class
• String.class
• System.class
• Object.class
24. JLINK : USES
• The default JRE contains 4000+ predefined Java .class files.
• If I execute my “hello world” application with the default JRE, then all
the predefined .class files will be executed. But if I only need 3-4 .class
files to execute my “hello world” application, then why I need to
maintain the outer .class files?
• The default JRE's size in jdk-8 is 203 MB. For executing my simple 1 KB
of code, I have to maintain 203 MB of JRE in my machine. It is a
complete waste of memory.
25. JLINK Commands :
jlink --module-path <modulepath> --add-modules <modules> --limit-
modules <modules> --output <path>
• –module-path specifies where to find the modules for the JDK. These
can be jar files, jmod files (a new file format with JDK 9 which is
similar to the jar format.
• –add-modules adds the modules we need (in this example our app)
• –limit-modules limits to just the modules that we know our
application needs (sometimes when modules are added, further
modules can be added via transitive dependencies. Here we can
specify that we only want certain modules)
• –output is this directory where the run-time image will be generated.
26. OSGI vs JPMS
OSGI JPMS
Framework Platform Feature. Was used to
modularize the java platform itself
Complex steep learning curve Simple when compared to OSGI
Solves many problems like JAR
Hell(Using classloaders),Circular
Dependency
Not solved/Not supported
27. Q & A
Links to code : https://github.com/vickii
Links to slide : https://www.slideshare.net/VigneshRamesh8
Linked in : https://www.linkedin.com/in/vickyramesh/
Twitter : https://twitter.com/vickiramesh
