A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/nipafx/demo-jpms-monitor/tree/feature-services below:

GitHub - nipafx/demo-jpms-monitor at feature-services

↗️ This README only covers one section of the demo. The master branch contains more information.

Services follow the service locator pattern and decouple the user of an API from its implementors.

In this example the monitor module declares that it uses the ServiceObserverFactory as a service:

module monitor {
	requires monitor.observer;
	// no more requires on alpha and beta observer modules!
	requires monitor.statistics;
	requires monitor.persistence;
	requires monitor.rest;

	uses ServiceObserverFactory;
}

Now monitor.observer.alpha and monitor.observer.beta declare that they provide that service:

module monitor.observer.alpha {
	requires monitor.observer;
	// no exports needed; API is well-encapsulated!
	provides monitor.observer.ServiceObserverFactory
		with monitor.observer.alpha.AlphaServiceObserverFactory;
}

And that's it from the module declaration side. The code in monitor loading those service looks as follows:

List<ServiceObserverFactory> observerFactories = ServiceLoader
		.load(ServiceObserverFactory.class).stream()
		.map(Provider::get)
		.collect(toList());

When it comes to building and executing these modules, the fact that there is no longer a dependency from monitor to the observer implementations may complicate matters:

To demonstrate that services in plain JARs still work the way they used to, I created an additional service monitor.observer.zero. It uses META-INF/services to declare ZeroObserverFactory and run.sh as well as Maven exec load it as an automatic module.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4