Java 9 introduced several new features including JShell, modules, and services. JShell allows developers to test Java code interactively from the command line. Modules allow Java code to be modularized by defining explicit dependencies and encapsulating packages. Services allow modules to discover implementations of an interface at runtime through a service loader. The modularization of Java aims to improve maintainability, security, and performance of Java applications.
Report
Share
Report
Share
1 of 60
Download to read offline
More Related Content
Java 9, JShell, and Modularity
1. Java & Beyond
Java 9
Mohammad Hossein Rimaz
K. N. Toosi University of Technology
KNTU Java User Group
4. What?
• JShell is a REPL (Read-Evaluate-Print Loop), a command line
tool which allows developer to coding in java without
building projects in IDEs or compiling and running their short
code which is quite lengthy task
• If you are familiar with interpreted language like Python or
other JVM languages like Groovy or Scala the concept of
JShell is familiar to you.
5. Why?
• Good for new programmers and beginners
• Good for testing language features
10. What? & Why?
• Java 9 was delayed so many times because of Project Jigsaw.
• You might have been hearing a lot about modules,
modularity, and other stuff.
• What it’s all about?
• What the heck is modularization and what do we mean by a
modularized platform?
• What's the Java Platform Module System (JPMS) all about?
• Is it going to be a revolution in Java ecosystem?
11. What? & Why?
• Maintainability is one of the most significant concerns in
software design and evolution.
• We want a code base that is loosely coupled, highly cohesive,
extremely readable, and can be understandable at a glance.
• We design our classes and organize them in packages.
• When we have hundreds of packages, the dependencies
between them are not visible at one look.
• We need something more than packages to organize our
code base to make it more maintainable.
12. What? & Why?
• Another problem is the Java classpath and how it runs our
codes.
• All JAR classes and libraries are flattened into the classpath.
When these JAR files have multiple version of a class on the
runtime, the Java ClassLoader can load only one version of
that class. In this way, there is ambiguity about how your
program is going to work, and ambiguity is a bad thing. This
issue is so frequent that you might know it as “JAR Hell.”
• Inefficient, Insecure, and even Dangerous!
13. What? & Why?
• Another problem with the classpath is that it doesn’t follow
the “Fail First” principle.
• You may have missing classes that exist in the classpath, but
not in the production environment. Until you get
the JavaClassDefError exception at runtime, you can’t be
sure what is missing.
14. What? & Why?
• Finally, the big issue with the classpath is encapsulation.
Every class on the classpath has access to each other, and
this is an encapsulation violation.
• We want to hide our internal APIs, and that’s why we need
another level of encapsulation (“Strong Encapsulation”) and
control over the access to our classes in our packages.
15. Uses of JDK Internal APIs:
Taken from: https://www.slideshare.net/haochenglee/prepare-for-jdk-9
17. What? & Why?
• Modules are going to fix these issues.
• What is a module? A module has a name, it groups related
code, and is self-contained.
• A module describes explicitly what it needs from other
modules and which part of it is visible to other modules.
18. What? & Why?
• In this manner, dependencies between modules are crystal
clear.
• We have Strong Encapsulation, which means we can hide
our internal APIs, and finally
• We now follow the “Fail First” principle. Therefore, when
there is a missing module or a conflict, you will get an error.
19. What? & Why?
• Modularizing the JDK allows JDK developers to manage the
huge complexity of it.
• When you write a tiny and straightforward application that
doesn’t use RMI, CORBA, Java EE, and other stuff, why do
you need a full, huge, and heavy JRE?
• Isn’t it wiser to have your runtime image only contain the
modules you need?
• Now with a modularized platform, it’s possible.
20. • Modularizing the JDK allows JDK developers to manage the
huge complexity of it.
• When you write a tiny and straightforward application that
doesn’t use RMI, CORBA, Java EE, and other stuff, why do
you need a full, huge, and heavy JRE?
• Isn’t it wiser to have your runtime image only contain the
modules you need?
• Now with a modularized platform, it’s possible.
What? & Why?
21. What? & Why?
• This is how the JDK now looks.
• On the bottom, we have the “java.base” module that every
other module implicitly or explicitly depends on.
• As you can see, this dependency graph is a DAG, which
means no circular dependencies allowed [at compile-time!].
23. What? & Why?
Review
•Strong Encapsulation.
•Handling Complexity through Modularization.
•Fail-First: No JAR HELL, No Conflict, No
ClassDefFoundError Exception.
•Custom Runtime Images, Smaller Footprint,
Better Performance.
24. How?
• The picture shows
essentially what a
module is.
• Each module has a
module descriptor called
“module-info.java.”
25. How?
• In the module-info.java
file, you describe the
name of your module,
what it requires to work,
and which packages are
visible outside this
module.
• So in its simplest form,
the module-info.java
looks like this image:
30. How?
Create Our First Modular Application Using Command-Line
• Compiling
javac --module-source-
path src -d out
srckntujug.hellomodulei
rackntuHelloWorld.java
srckntujug.hellomodule
module-info.java
31. How?
Create Our First Modular Application Using Command-Line
• Running
java --module-path out -m
kntujug.hellomodule/ir.ac.kntu.HelloWorld
-> Hello World
42. Details
Services
• Suppose we have an application that requests to all online
taxi services and request the cheapest taxi service.
chipsi.napsi chipsi.tapsi chipsi.maxsi
chipsi.taxifinder
45. Details
Services
• All of these approaches are wrong.
• Two known approach
• Factory Pattern : Still we should know about implementations
name.
• Dependency Injection
• But we can use Services and ServiceLoader
48. Details
• And so many advance features like
• Optional Dependencies
• Add Modules at Runtime
• Resource Encapsulation
• ServiceLoader Life Cycle
• Auto Modules
• Unnamed Modules
• You can refer to the provided references to learn about
them.
50. Other New Features
•Collections Factory
•HTTP/2, WebSocket, HTTP/1.1
•Stream API Improvements
•Reactive Streams with Flow API
•StackWalker
51. Other New Features
•JavaFX Enhancement and new APIs
•G1 Garbage Collector as Default GC
•Multi-Release JAR Files [JEP-238]
•Enhanced Deprecation
•HTML5 JavaDoc
•And so many other features and enhancements
…
54. Resources
• Java 9 Modularity
Patterns and Practices for
developing maintainable
applications
By Sander Mak & Paul Bakker
• Many examples and
descriptions of this slides taken
from this book
55. Resources
• Java 9 Recipes
A Problem-Solution Approach
By Josh Juneau
• A General Book about Java 9
56. Resources
• Java 9 Modularity Revealed
Project Jigsaw and Scalable
Java Applications
By Alexandru Jecan
• Yet another in depth java 9
modularity book.
57. JavaOne 2017 Talks:
• Modules in One Lesson
by Mark Reinhold
• Migration to Modules
by Mark Reinhold
• Modules and Services
by Alex Buckley
• Designing for Modularity with Java 9
by Sander Mak and Paul Bakker
58. Hands On Code:
Work with this GitHub repository.
https://github.com/AdoptOpenJDK/jdk9-jigsaw