JVM | Platform | Status |
---|---|---|
OpenJDK (Temurin) Current | Linux | |
OpenJDK (Temurin) LTS | Linux | |
OpenJDK (Temurin) Current | Windows | |
OpenJDK (Temurin) LTS | Windows |
A minimalist application service directory.
- Register and deregister application services.
- Subscribe to service events to be notified of changes.
- Written in pure Java 21.
- OSGi ready.
- JPMS ready.
- ISC license.
- High-coverage automated test suite.
Most applications end up using some kind of dependency injection. That is, a given class in an application is not responsible for instantiating the other classes on which it depends, but it instead has instances of those classes injected into its constructor. Many systems provide basically incomprehensible and error-prone annotation-based approaches that can be considered as push-based; a class has its own private fields reflectively assigned by an external system.
The repetoir
system provides a strongly-typed, easily-understood service
directory for pull-based dependency injection. An application creates
a service directory (a plain Java object) on startup, manually instantiates
and registers services into it, and then passes that service directory
around the application. Parts of the application that require services
explicitly pull those services from the service directory.
There is never any confusion, as is common with annotation and push-based dependency injection systems, where and how services are being instantiated; there is exactly one place in the code that creates services, and the instantiations are explicit and clearly visible.
Additionally, because the system is represented by a single, very simple interface type, there is no need to involve complicated mocking extensions in unit tests in order to get services correctly injected into all of the classes involves; simply create a service directory directly in the unit tests, publish the required services to it, and pass that directory into the classes under test.
$ mvn clean verify
Create a service directory:
var directory = new RPServiceDirectory();
Register services:
interface ExampleServiceType extends RPServiceType { }
class ExampleServiceService implements ExampleServiceType { }
directory.register(ExampleServiceType.class, new ExampleServiceService());
Later, fetch required services:
ExampleServiceType service =
directory.requireService(ExampleServiceType.class);
Fetch optional services:
interface ExampleOptionalServiceType extends RPServiceType { }
Optional<ExampleOptionalServiceType> service =
directory.optionalService(ExampleOptionalServiceType.class);
It is a requirement that services implement the trivial RPServiceType
interface in order to be registered in a directory. Services that also
implement AutoCloseable
will be closed when the service directory is
closed.