Advanced Features

Dependency Pruning

distage performs pruning of all unused bindings by default. When you configure a set of “root” keys - either explicitly by passing Roots or implicitly by using Injector#produceRun or Injector#produceGet methods, distage will remove all bindings that aren’t required to create the supplied roots – these bindings will be thrown out and not even considered, much less executed.

Pruning serves two important purposes:

• It enables faster tests by omitting unused instantiations and allocations of potentially heavy resources,
• It enables multiple independent applications, aka “Roles” to be hosted within a single binary.

Example:

import distage.{Roots, ModuleDef, Injector}

class A(b: B) {
  println("A!")
}
class B() {
  println("B!")
}
class C() {
  println("C!")
}

def module = new ModuleDef {
  make[A]
  make[B]
  make[C]
}

// create an object graph from description in `module`
// with `A` as the GC root

val objects = Injector().produce(module, Roots.target[A]).unsafeGet()
// B!
// A!
// objects: izumi.fundamentals.platform.functional.package.Identity[izumi.distage.model.Locator] = izumi.distage.LocatorDefaultImpl@30b42bf9

// A and B are in the object graph

objects.find[A]
// res1: Option[A] = Some(repl.MdocSession$MdocApp0$A@203a6115)

objects.find[B]
// res2: Option[B] = Some(repl.MdocSession$MdocApp0$B@237389a5)

// C is missing

objects.find[C]
// res3: Option[C] = None

Class C was removed because neither B nor A depended on it. It’s neither present in the Locator nor the "C!" message from it’s constructor was ever printed.

If you add c: C parameter to class B , like class B(c: C) - then C will be instantiated, because A - the “root”, will now depend on B, and B will depend on C.

class B(c: C) {
  println("B!")
}

val objects = Injector().produce(module, Roots.target[A]).unsafeGet()
// C!
// B!
// A!
// objects: izumi.fundamentals.platform.functional.package.Identity[Locator] = izumi.distage.LocatorDefaultImpl@53fed0f4

objects.find[C]
// res5: Option[C] = Some(repl.MdocSession$MdocApp4$C@4284d291)

Circular Dependencies Support

distage automatically resolves arbitrary circular dependencies, including self-references:

import distage.{DIKey, Roots, ModuleDef, Injector}

class A(val b: B)
class B(val a: A)
class C(val c: C)

def module = new ModuleDef {
  make[A]
  make[B]
  make[C]
}

val objects = Injector().produce(module, Roots(DIKey[A], DIKey[C])).unsafeGet()
// objects: izumi.fundamentals.platform.functional.package.Identity[izumi.distage.model.Locator] = izumi.distage.LocatorDefaultImpl@3145311d

objects.get[A] eq objects.get[B].a
// res7: Boolean = true

objects.get[B] eq objects.get[A].b
// res8: Boolean = true

objects.get[C] eq objects.get[C].c
// res9: Boolean = true

Automatic Resolution with generated proxies

The above strategy depends on distage-core-proxy-bytebuddy module and is enabled by default.

If you want to disable it, use NoProxies bootstrap configuration:

Injector.NoProxies()
// res10: Injector[izumi.fundamentals.platform.functional.package.Identity] = izumi.distage.InjectorDefaultImpl@e44a831

Proxies are not supported on Scala.js.

Manual Resolution with by-name parameters

Most cycles can be resolved without proxies, using By-Name parameters:

import distage.{DIKey, Roots, ModuleDef, Injector}

class A(b0: => B) {
  def b: B = b0
}

class B(a0: => A) {
  def a: A = a0
}

class C(self: => C) {
  def c: C = self
}

def module = new ModuleDef {
  make[A]
  make[B]
  make[C]
}

// disable proxies and execute the module

val locator = Injector.NoProxies()
  .produce(module, Roots(DIKey[A], DIKey[C]))
  .unsafeGet()
// locator: izumi.fundamentals.platform.functional.package.Identity[izumi.distage.model.Locator] = izumi.distage.LocatorDefaultImpl@2b98a07d

assert(locator.get[A].b eq locator.get[B])

assert(locator.get[B].a eq locator.get[A])

assert(locator.get[C].c eq locator.get[C])

The proxy generation via bytebuddy is enabled by default, because in scenarios with extreme late-binding cycles can emerge unexpectedly, out of control of the origin module.

Note: Currently a limitation applies to by-names - ALL dependencies of a class engaged in a by-name circular dependency must be by-name, otherwise distage will revert to generating proxies.

Weak Sets

Set bindings can contain weak references. References designated as weak will be retained only if there are other dependencies on the referred bindings, NOT if there’s a dependency only on the entire Set.

Example:

import distage.{Roots, ModuleDef, Injector}

sealed trait Elem

final case class Strong() extends Elem {
  println("Strong constructed")
}

final case class Weak() extends Elem {
  println("Weak constructed")
}

def module = new ModuleDef {
  make[Strong]
  make[Weak]

  many[Elem]
    .ref[Strong]
    .weak[Weak]
}

// Designate Set[Elem] as the garbage collection root,
// everything that Set[Elem] does not strongly depend on will be garbage collected
// and will not be constructed.

val roots = Roots.target[Set[Elem]]
// roots: Roots = Of(NESet({type.scala.collection.immutable.Set[=repl.MdocSession::MdocApp15::Elem]}))

val objects = Injector().produce(module, roots).unsafeGet()
// Strong constructed
// objects: izumi.fundamentals.platform.functional.package.Identity[izumi.distage.model.Locator] = izumi.distage.LocatorDefaultImpl@4f6cffc5

// Strong is around

objects.find[Strong]
// res16: Option[Strong] = Some(Strong())

// Weak is not

objects.find[Strong]
// res17: Option[Strong] = Some(Strong())

// There's only Strong in the Set

objects.get[Set[Elem]]
// res18: Set[Elem] = Set(Strong())

The Weak class was not required by any dependency of Set[Elem], so it was pruned. The Strong class remained, because the reference to it was strong, so it was counted as a dependency of Set[Elem].

If we change Strong to depend on the Weak, then Weak will be retained:

final class Strong(weak: Weak) extends Elem {
  println("Strong constructed")
}

val objects = Injector().produce(module, roots).unsafeGet()
// Weak constructed
// Strong constructed
// objects: izumi.fundamentals.platform.functional.package.Identity[izumi.distage.model.Locator] = izumi.distage.LocatorDefaultImpl@57b9e2ec

// Weak is around

objects.find[Weak]
// res20: Option[Weak] = Some(repl.MdocSession$MdocApp19$Weak@7c97cd0a)

// both Strong and Weak are in the Set

objects.get[Set[Elem]]
// res21: Set[Elem] = Set(repl.MdocSession$MdocApp19$Weak@7c97cd0a, repl.MdocSession$MdocApp19$Strong@126211ad)

Auto-Sets

AutoSet Planner Hooks can traverse the plan and collect all future objects that match a predicate.

Using Auto-Sets you can e.g. collect all AutoCloseable classes and .close() them after the application has finished work. NOTE: please use Resource bindings for real lifecycle, this is just an example.

import distage.{BootstrapModuleDef, ModuleDef, Injector}
import izumi.distage.model.planning.PlanningHook
import izumi.distage.planning.AutoSetHook

class PrintResource(name: String) {
  def start(): Unit = println(s"$name started")
  def stop(): Unit = println(s"$name stopped")
}

class A extends PrintResource("A")
class B(val a: A) extends PrintResource("B")
class C(val b: B) extends PrintResource("C")

def bootstrapModule = new BootstrapModuleDef {
  many[PlanningHook]
    .add(AutoSetHook[PrintResource])
}

def appModule = new ModuleDef {
  make[A]
  make[B]
  make[C]
}

val resources = Injector(bootstrapModule)
  .produceGet[Set[PrintResource]](appModule)
  .use(set => set)
// resources: izumi.fundamentals.platform.functional.package.Identity[Set[PrintResource]] = Set()

resources.foreach(_.start())
resources.toSeq.reverse.foreach(_.stop())

Calling .foreach on an auto-set is safe; the actions will be executed in order of dependencies - Auto-Sets preserve ordering, unlike user-defined Sets

e.g. If C depends on B depends on A, autoset order is: A, B, C, to start call: A, B, C, to close call: C, B, A. When using an auto-set for finalization, you must .reverse the autoset.

Note: Auto-Sets are assembled after Garbage Collection, as such they cannot contain garbage by construction. Because of this they effectively cannot be used as GC Roots.

Further reading:

• MacWire calls the same concept “Multi Wiring”

Depending on Locator

Objects can depend on the outer object graph that contains them (Locator), by including a LocatorRef parameter:

import distage.{DIKey, ModuleDef, LocatorRef, Injector, Roots}

class A(
  objects: LocatorRef
) {
  def c = objects.get.get[C]
}
class B
class C

def module = new ModuleDef {
  make[A]
  make[B]
  make[C]
}

val objects = Injector().produce(module, Roots(DIKey[A], DIKey[B], DIKey[C])).unsafeGet()
// objects: izumi.fundamentals.platform.functional.package.Identity[izumi.distage.model.Locator] = izumi.distage.LocatorDefaultImpl@3ad856f3

// A took C from the object graph

objects.get[A].c
// res26: C = repl.MdocSession$MdocApp25$C@72f07ed5

// this C is the same C as in this `objects` value

val thisC = objects.get[C]
// thisC: C = repl.MdocSession$MdocApp25$C@72f07ed5

val thatC = objects.get[A].c
// thatC: C = repl.MdocSession$MdocApp25$C@72f07ed5

assert(thisC == thatC)

Locator contains metadata about the plan, and the bindings from which it was ultimately created:

import distage.{Plan, ModuleBase}

// Plan that created this locator

val plan: Plan = objects.plan
// plan: Plan = 1: {type.LocatorRef} (advanced-features.md:347) := locator {type.LocatorRef} // required for {type.MdocSession::MdocApp25::A}
// 2: {type.MdocSession::MdocApp25::B} (advanced-features.md:348) := call(π:Class(): MdocSession::MdocApp25::B) {}
// 3: {type.MdocSession::MdocApp25::C} (advanced-features.md:349) := call(π:Class(): MdocSession::MdocApp25::C) {}
// 4: {type.MdocSession::MdocApp25::A} (advanced-features.md:347) :=
// 5:     call(π:Class(LocatorRef): MdocSession::MdocApp25::A) {
// 6:       arg objects: LocatorRef <- {type.LocatorRef}
// 7:     }

// Bindings from which the Plan was built (after GC)

val bindings: ModuleBase = plan.definition
// bindings: ModuleBase = 
// make[{type.repl.MdocSession::MdocApp25::B}].from(call(π:Class(): repl.MdocSession::MdocApp25::B)) ((advanced-features.md:348))
// make[{type.repl.MdocSession::MdocApp25::A}].from(call(π:Class(izumi.distage.model.recursive.LocatorRef): repl.MdocSession::MdocApp25::A)) ((advanced-features.md:347))
// make[{type.repl.MdocSession::MdocApp25::C}].from(call(π:Class(): repl.MdocSession::MdocApp25::C)) ((advanced-features.md:349))

Directly depending on Locator is a low-level API. If you only need to wire a subgraph within a larger object graph, you may be able to do this using a high-level Subcontexts API.

Injector inheritance

You may run a new planning cycle, inheriting the instances from an existing Locator into your new object subgraph:

val childInjector = Injector.inherit(objects)
// childInjector: Injector[[A]izumi.fundamentals.platform.functional.package.Identity[A]] = izumi.distage.InjectorDefaultImpl@2b884eb3

class Printer(a: A, b: B, c: C) {
  def printEm(): Unit =
    println(s"I've got A=$a, B=$b, C=$c, all here!")
}

childInjector.produceRun(new ModuleDef { make[Printer] }) {
  (_: Printer).printEm()
}
// I've got A=repl.MdocSession$MdocApp25$A@582e42b9, B=repl.MdocSession$MdocApp25$B@6fce19c3, C=repl.MdocSession$MdocApp25$C@72f07ed5, all here!
// res28: izumi.fundamentals.platform.functional.package.Identity[Unit] = ()

It’s safe, performance-wise, to run Injector to create nested graphs – Injector is extremely fast.

Bootloader

The plan and bindings in Locator are saved in the state they were AFTER Garbage Collection has been performed. Objects can request the original input via a PlannerInput parameter:

import distage.{Roots, ModuleDef, PlannerInput, Injector, Activation}

class InjectionInfo(val plannerInput: PlannerInput)

def module = new ModuleDef {
  make[InjectionInfo]
}

val input = PlannerInput(module, Activation.empty, Roots.target[InjectionInfo])
// input: PlannerInput = PlannerInput(
// make[{type.repl.MdocSession::MdocApp29::InjectionInfo}].from(call(π:Class(izumi.distage.model.PlannerInput): repl.MdocSession::MdocApp29::InjectionInfo)) ((advanced-features.md:410)),Activation(Map()),Of(NESet({type.repl.MdocSession::MdocApp29::InjectionInfo})))

val injectionInfo = Injector().produce(input).unsafeGet().get[InjectionInfo]
// injectionInfo: InjectionInfo = repl.MdocSession$MdocApp29$InjectionInfo@1501ce76

// the PlannerInput in `InjectionInfo` is the same as `input`

assert(injectionInfo.plannerInput == input)

Bootloader is another summonable parameter that contains the above information in aggregate and lets you create another object graph from the same inputs as the current or with alterations.

Inner Classes and Path-Dependent Types

Path-dependent types with a value prefix will be instantiated normally:

import distage.{Roots, ModuleDef, Injector}

class Path {
  class A
}
val path = new Path
// path: Path = repl.MdocSession$MdocApp31$Path@61b20cab

def module = new ModuleDef {
  make[path.A]
}

Injector()
  .produce(module, Roots.Everything)
  .use(_.get[path.A])
// res32: izumi.fundamentals.platform.functional.package.Identity[path.A] = repl.MdocSession$MdocApp31$Path$A@76ada206

Since version 0.10, support for types with a non-value prefix (type projections) has been dropped.

However, there’s a gotcha with value prefixes, when seen by distage they’re based on the literal variable name of the prefix, not the full type information available to the compiler, therefore the following usage, a simple rename, will fail:

def pathModule(p: Path) = new ModuleDef {
  make[p.A]
}

val path1 = new Path
// path1: Path = repl.MdocSession$MdocApp31$Path@1f3997b6
val path2 = new Path
// path2: Path = repl.MdocSession$MdocApp31$Path@4508859

Try {
  Injector().produceRun(pathModule(path1) ++ pathModule(path2)) {
    (p1a: path1.A, p2a: path2.A) =>
      println((p1a, p2a))
  }
}.isFailure
// res33: Boolean = true

This will fail because while path1.A and p.A inside new ModuleDef are the same type as far as Scala is concerned, the variables path1 & p are spelled differently and this causes a mismatch in distage.

There’s one way to workaround this - turn the type member A into a type parameter using the Aux Pattern, and then for that type parameter in turn, summon the type information using Tag implicit (as described in Tagless Final Style chapter) and summon the constructor using the ClassConstructor implicit, example:

import distage.{ClassConstructor, ModuleDef, Injector, Tag}

object Path {
  type Aux[A0] = Path { type A = A0 }
}

def pathModule[A: Tag: ClassConstructor](p: Path.Aux[A]) = new ModuleDef {
  make[A]
}

val path1 = new Path
// path1: Path = repl.MdocSession$MdocApp34$Path@75f61b2c
val path2 = new Path
// path2: Path = repl.MdocSession$MdocApp34$Path@6ed02a06

Injector().produceRun(pathModule(path1) ++ pathModule(path2)) {
  (p1a: path1.A, p2a: path2.A) =>
    println((p1a, p2a))
}
// (repl.MdocSession$MdocApp34$Path$A@3f5a566e,repl.MdocSession$MdocApp34$Path$A@5c38a8c8)
// res35: izumi.fundamentals.platform.functional.package.Identity[Unit] = ()

Now the example works, because the A type inside pathModule(path1) is path1.A and for pathModule(path2) it’s path2.A, which matches their subsequent spelling in (p1a: path1.A, p2a: path2.A) => in produceRun