↗️ 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:

• The multi-compilation build needs --add-modules=monitor.observer.alpha,monitor.observer.beta to include them.
• Maven builds them correctly as long as the parent POM mentions them, but without that dependency the exec plugin doesn't put the implementations on the module path when launching the app. This is less of a problem in this particular configuration, because exec is executed in the parent POM (instead of the module with the executable, which is more common).

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.