- Introduction
- Understanding the Java Platform Module System
- From Monolithic to Modular: The Evolution of the JDK
- Continuing the Evolution: Modular JDK in JDK 11 and Beyond
- Implementing Modular Services with JDK 17
- JAR Hell Versioning Problem and Jigsaw Layers
- Open Services Gateway Initiative
- Introduction to Jdeps, Jlink, Jdeprscan, and Jmod
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Implementing Modular Services with JDK 17
With the JDK’s modular approach, we can enhance the concept of services (introduced in Java 1.6) by decoupling modules that provide the service interface from their provider module, eventually creating a fully decoupled consumer. To employ services, the type is usually declared as an interface or an abstract class, and the service providers need to be clearly identified in their modules, enabling them to be recognized as providers. Lastly, consumer modules are required to utilize those providers.
To better explain the decoupling that occurs, we’ll use a step-by-step example to build a BricksProvider along with its providers and consumers.
Service Provider
A service provider is a module that implements a service interface and makes it available for other modules to consume. It is responsible for implementing the functionalities defined in the service interface. In our example, we’ll create a module called com.example.bricksprovider, which will implement the BrickHouse interface and provide the service.
Creating the com.example.bricksprovider Module
First, we create a new directory called bricksprovider; inside it, we create the com/example/bricksprovider directory structure. Next, we create a module-info.java file in the bricksprovider directory with the following content:
module com.example.bricksprovider {
requires com.example.brickhouse;
provides com.example.brickhouse.BrickHouse with com.example.bricksprovider.BricksProvider;
}
This module-info.java file declares that our module requires the com.example.brickhouse module and provides an implementation of the BrickHouse interface through the com.example.bricksprovider.BricksProvider class.
Now, we create the BricksProvider.java file inside the com/example/bricksprovider directory with the following content:
package com.example.bricksprovider;
import com.example.brickhouse.BrickHouse;
public class BricksProvider implements BrickHouse {
@Override
public void build() {
System.out.println("Building a house with bricks...");
}
}
Service Consumer
A service consumer is a module that uses a service provided by another module. It declares the service it requires in its module-info.java file using the uses keyword. The service consumer can then use the ServiceLoader API to discover and instantiate implementations of the required service.
Creating the com.example.builder Module
First, we create a new directory called builder; inside it, we create the com/example/builder directory structure. Next, we create a module-info.java file in the builder directory with the following content:
module com.example.builder {
requires com.example.brickhouse;
uses com.example.brickhouse.BrickHouse;
}
This module-info.java file declares that our module requires the com.example.brickhouse module and uses the BrickHouse service.
Now, we create a Builder.java file inside the com/example/builder directory with the following content:
package com.example.builder;
import com.example.brickhouse.BrickHouse;
import java.util.ServiceLoader;
public class Builder {
public static void main(String[] args) {
ServiceLoader<BrickHouse> loader = ServiceLoader.load(BrickHouse.class);
loader.forEach(BrickHouse::build);
}
}
A Working Example
Let’s consider a simple example of a modular Java application that uses services:
com.example.brickhouse: A module that defines the BrickHouse service interface that other modules can implement
com.example.bricksprovider: A module that provides an implementation of the BrickHouse service and declares it in its module-info.java file using the provides keyword
com.example.builder: A module that consumes the BrickHouse service and declares the required service in its module-info.java file using the uses keyword
The builder can then use the ServiceLoader API to discover and instantiate the BrickHouse implementation provided by the com.example.bricksprovider module.
)
Figure 3.3 Modular Services
Figure 3.3 depicts the relationships between the modules and classes in a module diagram. The module diagram represents the dependencies and relationships between the modules and classes:
The com.example.builder module contains the Builder.java class, which uses the BrickHouse interface from the com.example.brickhouse module.
The com.example.bricksprovider module contains the BricksProvider.java class, which implements and provides the BrickHouse interface.
Implementation Details
The ServiceLoader API is a powerful mechanism that allows the com.example.builder module to discover and instantiate the BrickHouse implementation provided by the com.example.bricksprovider module at runtime. This allows for more flexibility and better separation of concerns between modules. The following subsections focus on some implementation details that can help us better understand the interactions between the modules and the role of the ServiceLoader API.
Discovering Service Implementations
The ServiceLoader.load() method takes a service interface as its argument—in our case, BrickHouse.class—and returns a ServiceLoader instance. This instance is an iterable object containing all available service implementations. The ServiceLoader relies on the information provided in the module-info.java files to discover the service implementations.
Instantiating Service Implementations
When iterating over the ServiceLoader instance, the API automatically instantiates the service implementations provided by the service providers. In our example, the BricksProvider class is instantiated, and its build() method is called when iterating over the ServiceLoader instance.
Encapsulating Implementation Details
By using the JPMS, the com.example.bricksprovider module can encapsulate its implementation details, exposing only the BrickHouse service that it provides. This allows the com.example.builder module to consume the service without depending on the concrete implementation, creating a more robust and maintainable system.
Adding More Service Providers
Our example can be easily extended by adding more service providers implementing the BrickHouse interface. As long as the new service providers are properly declared in their respective module-info.java files, the com.example.builder module will be able to discover and use them automatically through the ServiceLoader API. This allows for a more modular and extensible system that can adapt to changing requirements or new implementations.
Figure 3.4 is a use-case diagram that depicts the interactions between the service consumer and service provider. It includes two actors: Service Consumer and Service Provider.
Service Consumer: This uses the services provided by the Service Provider. The Service Consumer interacts with the Modular JDK in the following ways:
Discover Service Implementations: The Service Consumer uses the Modular JDK to find available service implementations.
Instantiate Service Implementations: Once the service implementations are discovered, the Service Consumer uses the Modular JDK to create instances of these services.
Encapsulate Implementation Details: The Service Consumer benefits from the encapsulation provided by the Modular JDK, which allows it to use services without needing to know their underlying implementation.
Service Provider: This implements and provides the services. The Service Provider interacts with the Modular JDK in the following ways:
Implement Service Interface: The Service Provider uses the Modular JDK to implement the service interface, which defines the contract for the service.
Encapsulate Implementation Details: The Service Provider uses the Modular JDK to hide the details of its service implementation, exposing only the service interface.
Add More Service Providers: The Service Provider can use the Modular JDK to add more providers for the service, enhancing the modularity and extensibility of the system.
)
Figure 3.4 Use-Case Diagram Highlighting the Service Consumer and Service Provider
The Modular JDK acts as a robust facilitator for these interactions, establishing a comprehensive platform where service providers can effectively offer their services. Simultaneously, it provides an avenue for service consumers to discover and utilize these services efficiently. This dynamic ecosystem fosters a seamless exchange of services, enhancing the overall functionality and interoperability of modular Java applications.