Problem
To work around the access restrictions described in Proposal 2, we use the split-package pattern — placing a helper class in io.nats.client.impl across JAR boundaries. This gives us access to the members we need (ApConnection, ApConnection.passive, ApConnection.apServerPool) but is incompatible with the Java Module System (JPMS). If jnats or java-active-passive ever adds a module-info.java with restricted package exports, our integration will fail to compile or load.
The members we need access to, and why:
| Member |
Visibility |
Why we need it |
ApConnection (the type itself) |
Package-private export |
Cannot hold a typed reference from outside impl |
ApConnection.passive |
Package-private field |
Need passive's connected URL for LDM deprioritization |
ApConnection.apServerPool |
Package-private field |
Need to read activeServerRef and call setActiveServer() |
Proposed resolution
Implement Proposals 1 and 2. Once those are available, our split-package workaround can be removed entirely and replaced with the clean public APIs — no additional API surface needed beyond Proposals 1 and 2.
Problem
To work around the access restrictions described in Proposal 2, we use the split-package pattern — placing a helper class in
io.nats.client.implacross JAR boundaries. This gives us access to the members we need (ApConnection,ApConnection.passive,ApConnection.apServerPool) but is incompatible with the Java Module System (JPMS). If jnats or java-active-passive ever adds amodule-info.javawith restricted package exports, our integration will fail to compile or load.The members we need access to, and why:
ApConnection(the type itself)implApConnection.passiveApConnection.apServerPoolactiveServerRefand callsetActiveServer()Proposed resolution
Implement Proposals 1 and 2. Once those are available, our split-package workaround can be removed entirely and replaced with the clean public APIs — no additional API surface needed beyond Proposals 1 and 2.