Gain insights into Java 17, cloud and microservices, reactive programming, and top JVM languages. Explore hands-on projects using Scala, Groovy, and Gradle to boost your software development career.

Modern Java Second Edition by Adam L. Davis.png

file.tar.gz

modern_java

Groovy

Scala

Java 12

Java 14

Java 16

Java 17

Java 16-copy

Play

jshell

SPA-play

Gradle-uppercase

Gradle-copyimages

Gradle-properties

Java 14-copy

Java 16-fruits

Java 16-strings

Gradle-java

This course is meant for Java programmers or aspiring programmers who want to know about the latest Java and JVM technology. Throughout this course, you will get several opportunities to get hands-on experience with various Java concepts. 

This course will help you understand the latest in Java up to version 17; cloud and microservices; build, testing, and web frameworks; reactive programming in Java; and the best JVM languages so you can advance your career in software development. 

Moreover, you will also get to work with Scala, Groovy, and Gradle. The course explains Java concepts in detail and also draws comparisons with its older versions, as well as JVM languages.

The All-in-One Guide to Java Programming

# What are the module system addresses?




Project Jigsaw includes both a module system and the ability to use a smaller subset of the JDK.

The classic classpath is still supported, but the module system adds additional functionality.

If you’ve ever developed a large application, you’ve probably experienced an exception caused by a
missing jar file or even worse, random errors caused by having more than one version of the same
dependency. Up until Java 8, a dependency is not enforced until it is needed at runtime. The module
system addresses these problems.

The module system in Java 9+ (9 and above) allows developers to enforce dependencies at compile-time and start-up, which uncovers problems faster and earlier, thus improving software reliability.

The second part of Project Jigsaw is that the JDK has been split into modules using the module system. The core module `java.base` will always be included by default. But other modules such as `java.sql` and `java.xml` will need to be specifically requested. This allows developers to rely on a smaller subset of the JDK and create applications with smaller footprints. This can be useful, for example, in either microservices or small devices with limited memory.

The core of the system is the `module-info.java` file that developers define for each module. It consists of a module name, which modules are required, what packages it exports, and what services it uses or provides (if any).
 

**module-info.java**
``` Java
module com.foo.bar {
   requires thing.you.need;
   exports com.mypackage;
}
```
Here, the module is named `com.foo.bar`. It requires the module named `thing.you.need`, and it exports the `com.mypackage` package.

We can have multiple `requires` and `exports` statements.

To compile a module, we must provide specific options to javac. Without these options, javac will work like it has in the past.


**Compile**

For example, the following command uses module-path `modules` to output to the directory `modules/-foo.bar`. It uses source-path `src` and the `find` command to compile every Java file found in the following manner:

``` java
$ javac -d modules/foo.bar --module-path modules -sourcepath src \
   `find src -name '*.java'`
```

>The `--module-path` option can be shortened to `-p`.

## Reflection protection
Before Java 9, any class could be inspected at runtime with reflection, even its private members, whether we wanted to allow this capability or not. Thus, nothing was truly encapsulated.

Java 9 adds the `open`, `opens`, and `opens…to` directives so that we can specify exactly what packages are open to reflection at runtime.


``` java
opens _package_
```

This specifies that all members of a package are available for runtime reflection.

``` java
opens _package_ to _comma_separated_list_of_modules_
```
This would open a package only to the listed modules.

Putting `open` before our module declaration allows reflection on any member of our module.

``` java
open module modulename {
}
```

## Providing and consuming services

Within our module definition, we can also specify service directives.
``` java
provides com.foo.Bar with com.my.BarImpl
```
A `provides…with` module directive specifies that a module provides a service implementation (making the module a service provider). The provides part of the directive that specifies an interface (or abstract class) listed in a module’s `uses` directive, and the `with` part of the directive specifies the class that implements that interface.

A `uses` module directive specifies a service used by this module (making the module a service consumer). For example:


``` java
uses com.foo.Bar
```
### Service
A **service** is an object of a class that implements the interface or extends the abstract class specified in the `uses` directive.

This enables the Java module system to ensure that there is a provider for the API classes that are specified in any `uses` directives.

We load services using the ServiceLoader, which has existed for many years in Java.


>The old way to define services required putting the name of the implementation class in a file under `META-INF/services/`. The filename is the interface’s name or abstract class.

For example, to get the ServiceLoader for a particular API (WidgetFactory in this case), we do something like the following:
```java
ServiceLoader<WidgetFactory> loader = ServiceLoader.load(WidgetFactory.class);
```
We can then use `loader.stream()` to get a Stream of implementations of WidgetFactory or `loader.iterator()` to get an Iterator.

We can use the Stream to filter and then do something with the result. For example:

``` java
loader.stream().filter(_your_filter_).findFirst()
    .ifPresentOrElse(factory -> doSomething(factory), _handle_missing_);
```

## Creating jars
Use the `jar` command to create modular jars.

``` java
jar -cfe lib/hello.jar com.hello.HelloWorldApp
    -C modules/foo.bar .
```
This creates a jar named `hello.jar` with main-class `com.hello.HelloWorldApp` and includes all files under `modules/foo.bar`.

>As shown above, `-cfe` is short for `–create –file –main-class` options of the jar command.

The presence of the `module-info.class` file is what makes this jar a module.

## Migrating to modules
We can migrate to modules using a “top-down” or “bottom-up” approach.

In the “top-down,” we modularize the project on “top” that has dependencies but nothing depends on it, such as the end application. In this case, we can require our dependencies as “automatic modules.”

**Automatic modules** are created when a non-module JAR is put on the module-path. This module has the same name as the jar name. The `.jar` extension is removed from the name,  any hyphens (`-`)are replaced by dots (`.`), and the version part is removed.

For example, given the following java command:

``` java
java --module-path apache-commons-io-2.1.jar --module app/com.app.Main
```
The automatic module `apache.commons.io` will be created. The module still has to explicitly import the jar module by its name using the `requires` clause in module-info.java. To require it, we would use the following module-info.java:

``` java
module foo.bar {
     requires apache.commons.io;
}
```
In the “bottom-up,” we start by modularizing each of our dependencies one-by-one and modularize the application layer at the end. This can only work if we control the dependency projects.

Which way you choose depends on your specific circumstances. Pick whichever is easier for your
case.


Modularity

Introduction

Java Syntax and Conventions

Java 7

Idiomatic Java 8: Lambdas, Streams, and Dates

New Date and Time API

Java 8 Miscellaneous

Advantages of Java 9

Java 10 - 17

Java Ecosystem

Maven and JUnit

Utilizing Essential Libraries

Modern Java Concurrency

RxJava

Other JVM Languages

Groovy

Gradle

Spock

Scala

RESTful

Microservices and Clouds

Grails

Spark

Spring Boot

Play Framework

Ratpack

Final Thoughts

Appendix

Modularity

What are the module system addresses?