0% found this document useful (0 votes)
13 views10 pages

Understanding Java Modules in Java 9

The document discusses the Java Platform Module System (Java modules) introduced in Java 9. Key points include: - Modules group related packages and add encapsulation beyond jars by controlling which packages are exposed. - Standard modules contain standard and non-standard API packages prefixed with "java." or "javax.". Non-standard modules start with "jdk." - Modules can be examined from the command line using tools like java --list-modules. - A module is defined in a module-info.java file and may export or require other module packages. Modular applications run on a modulepath instead of a classpath.

Uploaded by

aravind kumar
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views10 pages

Understanding Java Modules in Java 9

The document discusses the Java Platform Module System (Java modules) introduced in Java 9. Key points include: - Modules group related packages and add encapsulation beyond jars by controlling which packages are exposed. - Standard modules contain standard and non-standard API packages prefixed with "java." or "javax.". Non-standard modules start with "jdk." - Modules can be examined from the command line using tools like java --list-modules. - A module is defined in a module-info.java file and may export or require other module packages. Modular applications run on a modulepath instead of a classpath.

Uploaded by

aravind kumar
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd

Java Platform Module System( Java Modules)

Java modules was introduced in Java 9.


Module is all about structural changes in java application.

Before Java 9, the JDK was a monolithic set of packages, packaged in one jar file,
the [Link], which any java application would need to deploy alongwith it's own
code.

[Link]:
[Link] contains all of the compiled class files for the base Java Runtime
environment, as well as the bootstrap classes, which are the run time classes that
comprise the Java platform core API.

Module is a group of packages. But unlike jars, modules add another level of
encapsulation where all the packages may not be exposed to outside environment.
Also, an application can mention on what all modules they require for their
application.

Standard modules:
All of the modules in the Java SE are standard modules as defined by the JCP.
A standard module, may contain both standard and non-non standard API packages.
A standard package is prefixed with "java." or "javax.", like [Link] ....

Non-standard modules:
The JDK: jdk APIs are specific to the JDK.
These APIs are in modules whose names start with a "jdk." prefix.
A non-standard module must not export any standard API packages.

examining modules from the command line:

java --list-modules
java --describe-module [Link]

jDeps: Java Class Dependency Analyzer

-m: module

jdeps --print-module-deps -m [Link]


jdeps --print-module-deps --module [Link]

jdeps --list-deps -m [Link]


jdeps --list-reduced-deps -m [Link]

Creating a Module in Java:

[Link]

module myfirstmodule{

module [Link]{

In an application, there can be several modules, and each module contains precisely
one [Link]
myfirstmodule
--src
--[Link]
---[Link]
---[Link]
--[Link]
--[Link]
--[Link]

mysecondmodule
--src
--[Link]
---[Link]
---[Link]
--[Link]
--[Link]
--[Link]

We can also package the above compilation output in a JAR(modular jar) file.
[Link]
--META-INF
--[Link]
--[Link]
---[Link]
---[Link]
--[Link]
--[Link]
--[Link]

firstmodule
--src
--[Link]
--[Link]
--[Link]

Non-modular java application:


C:\Program Files\jdk-16.0.2\bin\[Link]
-[Link]=Cp1252
-classpath "D:\OCP-NEW BATCH\OCP Demos\FirstModule\bin"
-XX:+ShowCodeDetailsInExceptionMessages [Link]

Non-modular java applications run on "classpath" but modular java applications run
on "modulepath"

Module java application:


C:\Program Files\jdk-16.0.2\bin\[Link]
-[Link]=Cp1252
-p "D:\OCP-NEW BATCH\OCP Demos\TestModule\bin"
-XX:+ShowCodeDetailsInExceptionMessages
-m testmodule/[Link]

-p: module path


-m: module name
-d: directory in which you want to place your class files. By default eclipse use
bin folder. IntelliJ, uses out folder.

javac -d bin src/com/lti/greet/[Link] src/[Link]

bin
--firstmodule
--[Link]
--[Link]
--[Link]

java -p bin -m firstmodule/[Link]

java -p bin --describe-module firstmodule

Create a modular jar:


jar --create --file [Link] --main-class [Link] -C bin/ .

running a jar file:


java -jar [Link]

jdeps --module-path bin [Link]

----------------------------------------------
Module created in project "Global":

module name: [Link]


--src
--[Link]/[Link]
--[Link]/[Link]
--[Link]{
exports [Link];
exports [Link];
}

Module created in project "Client":


module name: [Link]
--src
--[Link]/[Link]
--[Link]{
require [Link]
}

java -p bin --describe-module [Link]

-------------------------------------------------------------------------------

[Link]--------(required)---------->[Link]-----------(required
transitive)---->[Link]
export [Link]
exports [Link]
exports
[Link]
Module created in project "Util":
module name: [Link]
--src
--[Link]/[Link]
--[Link]{
require transitive [Link]
exports [Link]
}

Module created in project "Base":


module name: [Link]
--src
--[Link]/[Link]
--[Link]{
require [Link]
}

jdeps --module-path bin -m [Link]


jdeps --module-path bin;"D:\OCP-NEW BATCH\OCP Demos\Global\bin" -m [Link]
jdeps --module-path bin;"D:\OCP-NEW BATCH\OCP Demos\Util\bin";"D:\OCP-NEW BATCH\OCP
Demos\Global\bin" -m [Link]

Friendly module: Qualified exports


exports [Link] to [Link],[Link];

Cyclic dependency is not allowed.

1. Direct cycle:

[Link]----------->[Link]
[Link]<-----------[Link]

2. Indirect cycle

[Link]----------->[Link]
[Link]<-----------[Link]
[Link]------------>[Link]

--------------------------------------------Services in
Modules-----------------------------------------------------------------

Project Name: Service


module1: [Link]
[Link]/ServiceRegistry(interface)-->greetings()
[Link]{
exports [Link];
}

Project Name: ProviderOne


module2: [Link]
[Link].impl1/Serviceimpl1(class) which implements the ServiceRegistry
interface---->override the greetings method
[Link]{
require [Link];
provides [Link]
with [Link].impl1.Serviceimpl1
}

Project Name: ProviderTwo


module3: [Link]
[Link].impl2/Serviceimpl2(class) which implements the ServiceRegistry
interface---->override the greetings method
[Link]{
require [Link];
provides [Link]
with [Link].impl2.Serviceimpl2
}

Project Name: Consumer


module4: [Link]
[Link]{
require [Link];
uses [Link]
}

opens [Link]; //reflexive access


opens [Link] to [Link];

-------------------------------------------------
Quiz-------------------------------------------------------------------------------
Question 1:
Your application is packaged in [Link] and depends on a jar named [Link],
which in turn depends on [Link]. The following packages
exist in these jars:

[Link]: [Link]
[Link]: [Link]
[Link]: [Link]

You have decided to modularize your application even though datalayer and mysql
libraries are still not modularlized. Which of the following would be a valid
module-info for your app?
A. module [Link]{
requires [Link];
}
B. module [Link]{
exports [Link];
}
C. module [Link]{
requires datalayer;
}
[Link] [Link]{
requires datalayer;
requires mysql-connector-java;
}
E. module [Link]{
requires datalayer;
requires mysql-connector-java-0.0.11;
}
F. module [Link]{
requires [Link];
requires [Link];
}

Question 2:

Identify correct statements about the module system of Java.

A. Only an application structured as modular can be run on a modular JDK.

B. Main goals of the module system are to improve security with strong
encapsulation and stability with reliable dependencies.

C. Code in modules and traditional JARs on the classpath cannot coexist in an


application.

D. Modules have concealed packages for internal use and exported packages for
shared code with other modules.

Question 4:
Which of the following are valid module definitions?

A.
//In file [Link]:
module autos{
}
B.
//In file [Link]:
module autos{
}
C.
//In file [Link]:
module autos{
}
D.
//In file [Link]:
module cars{
exports [Link];
}
module trucks{
requires cars;
}
E.
//In file [Link]:
module-info autos{
}

Question 6:

You are creating an [Link] module that depends on [Link] module and
makes its [Link] package available to all other modules. Which of the
following files correctly defines this module?

A. //In file [Link]:


module [Link]{
requires [Link];
exports [Link];
}
B. //In file [Link]:
module [Link]{
requires [Link].*;
exports [Link].*;
}
C. //In file [Link]:
module [Link]{
requires [Link];
exports [Link].*;
}
D. //In file [Link]:
module-info [Link]{
requires [Link];
exports [Link];
}
E. //In file [Link]:
module [Link]{
requires [Link];
exports [Link];
}

Question 8:
Given:
module broker{
exports [Link];
}
The broker module contains [Link] interface, which is implemented
by [Link] class of [Link] module.
Which of the following is a valid module definition for [Link] module?
A. module [Link]{
exports broker;
}
B. module [Link]{
provider broker;
}
module [Link]{
requires broker;
provides [Link];
}
C. module [Link]{
requires broker;
exports [Link];
provides [Link] with [Link];
}
D. module [Link]{
exports [Link];
provides [Link] with [Link];
}

Question 9:

Given the following contents of [Link],

module [Link]{
exports [Link];
requires [Link];
}
Select correct statements.

A. Module name is finance.


B. [Link] is the name of the class that this module exports.
C. This module depends on [Link] package.
D. This file must be present in [Link] directory if the source code is to be
compiled using the --module-source-path option.
E. Other modules that depend on this module will be able to access
[Link] package as well as [Link] package.
MyApp
|
|-[Link]
|
|--[Link]
| src
| --[Link]/[Link]
| --[Link]/[Link]
| --[Link]
|
|-- [Link]
src
--[Link]/[Link]
--[Link]/[Link]
--[Link]

-m myfirstmodule ---------> --moudule-source-path [Link]

Common questions

Powered by AI

The 'module-info.java' file is foundational in defining a Java module, serving as the module's descriptor. It specifies the module's dependencies ('requires'), exported packages ('exports'), service usage ('uses'), and service provisioning ('provides...with...'). By declaring these elements, it dictates how a module interacts with others, aids in enforcing encapsulation, and contributes to the reduction of classpath pollution by imposing clear dependency boundaries and ensuring access control .

Providing and consuming services in modules is crucial for modular applications to enable loose coupling and flexibility through service provider interfaces. A module can declare a service using the 'provides...with...' statement in module-info.java, indicating an implementation for the service interface. Another module can consume this service using the 'uses' statement. This mechanism allows implementations to be replaced or added without changing the consumer code, facilitating maintainability and extensibility in modular systems .

Java modules, introduced in Java 9, enhance application structure by grouping related packages and providing a new level of encapsulation, unlike traditional JAR files which do not restrict access to their contents. Modules can specify dependencies on other modules and can also hide internal packages from other modules, thus improving encapsulation. Moreover, they can declare what packages are exported, explicitly defining the module's API and reducing dependencies to only necessary packages .

A 'transitive' dependency occurs when a module not only requires another module but also makes its required module's exports available to modules that depend on it. This ensures that any module that requires the transitive module also has access to the required modules' exports without explicitly stating it in its module-info file. It simplifies dependency management in complex module graphs by propagating access to necessary components downstream .

A modular JAR includes a module-info.class file which defines the module's metadata, such as its dependencies and exported packages, providing greater declarative control over the module structure. In contrast, a traditional JAR does not impose structural constraints, bundling everything in a single file without clear package boundaries. Running a modular JAR involves specifying the module path, enabling the JVM to enforce strong encapsulation and dependency checks at runtime, whereas a traditional JAR simply requires adding it to the classpath, sacrificing modularity for simplicity .

A non-modular Java application relies on the classpath mechanism, where all library dependencies and code must be explicitly included in the classpath, often resulting in conflicts due to classpath pollution. Conversely, a modular Java application uses the module path, a more structured approach where each module specifies its dependencies in a module-info.java file. This allows the Java runtime to ensure the application only accesses specified modules, leading to clearer dependency management and reduced risk of runtime conflicts .

The Java module system aids backward compatibility by allowing modular applications to use legacy, non-modular libraries on the classpath. Modular and non-modular components can coexist, where the module system treats classpath elements as implicit modules with open access to all packages. This approach enables gradual migration to modularity without immediately requiring changes to all dependencies, supporting a smoother transition path .

To investigate dependencies and structure of modules, Java offers command-line tools like 'java --list-modules' to display available modules, 'java --describe-module <module>' to reveal details of a specific module, and 'jdeps' to analyze class dependencies within modules. By using 'jdeps' with flags like '--print-module-deps' and '--list-reduced-deps', developers can identify module dependencies and uncover which modules are needed for a given module or application, facilitating better module management .

The main goals of the Java module system include improving security through strong encapsulation and enhancing stability with reliable dependencies. By hiding non-essential packages and explicitly defining module dependencies, the system minimizes the risk of accidental exposure of internal components .

Cyclic dependencies in Java modules are problematic as they can lead to complex, unpredictable module graphs that complicate understanding and maintenance. They can cause issues like deadlock during module loading and make it difficult to manage and reason about dependencies' transitive closure. Avoiding cycles ensures a clear, hierarchical dependency structure which improves the module system's reliability and predictability .

You might also like