Constructor injection was the wrong call, for the reasons raised in
review: it publishes every dependency in a signature, so changing an
internal dependency becomes an API change and a binary compatibility
break unless old constructors are kept forever. It also cannot serve the
ServiceLoader tier, which requires a public no-arg constructor or a
static provider() factory.

The premise behind it was also wrong. I had assumed that letting the
container instantiate a plugin means exporting its package, which would
indeed break encapsulation -- callers could cast to implementations and
call non-API methods. But `opens` is not `exports`: a qualified
`opens <pkg> to <container>` grants deep reflective access at runtime
while leaving the package invisible at compile time.

Measured with a three-module test project on JDK 21, rather than assumed:

- ServiceLoader finds a provider declared with `provides` in a package
  that is neither exported nor opened.
- Reflective newInstance on such a package fails with
  IllegalAccessException; with a qualified `opens` it succeeds.
- setAccessible injection into a private field works with that opens.
- An ordinary module importing a class from the opened but unexported
  package fails to compile: "package ... is declared in module ..., which
  does not export it".
- A service with a private constructor and a public static provider()
  factory works; ServiceLoader prefers the factory.

So declarative field injection survives JPMS intact, encapsulation is
preserved, and the cost to a plugin module is one `opens` line. The claim
that we must give up private-field injection is removed.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_013gJpzGd3ksbME4CN6Tu2ni