gRPC Java 1.44.0 switches default load‑balancing policy from pick_first to round_robin

Answer first

Do not pin gRPC-Java to a pre-1.44.0 release. Pinning forgoes security and bug fixes and creates dependency drift with protobuf and Netty. Make the policy explicit in your channel construction and share that construction code across local workstations and CI.

For a repeatable local debug setup the robust approach is:

1. Centralize channel creation in a factory or config class used by both local dev and CI.
2. Set the policy explicitly on the builder: ManagedChannelBuilder.forAddress(...).defaultLoadBalancingPolicy("pick_first")
3. Lock the gRPC-Java version in a dependency lock file and verify the resolved version in CI and locally.

That gives deterministic behavior independent of library defaults and avoids version pinning.

Confirmed facts vs likely explanation

What can be confirmed

• gRPC-Java exposes ManagedChannelBuilder.defaultLoadBalancingPolicy(String) to override the channel-level default.
• A service config supplied via defaultServiceConfig or by a name resolver can set loadBalancingConfig. That service config overrides the builder default.
• Explicit policy selection is the recommended way to make behavior repeatable across environments.

What is unverified

The claim that gRPC-Java 1.44.0 changed the channel-level default from pick_first to round_robin could not be confirmed from available knowledge. The documented channel-level default has long been pick_first, and the 1.44.0 change is treated as unverified until checked against the official 1.44.0 release notes and LoadBalancer documentation. Behavior may also differ by resolver type.

Why explicit policy beats pinning

• Pinning to pre-1.44.0 forgoes security patches, bug fixes, and compatibility with newer server features.
• Pinning increases risk of transitive dependency conflicts with protobuf and Netty.
• Explicit defaultLoadBalancingPolicy("pick_first") documents intent in code and survives library upgrades.

Service config is an alternative, but it is more verbose for a local dev case. If you already use a shared service config, set loadBalancingConfig to pick_first there instead of relying on builder defaults.

Practical verification

• Check the resolved gRPC-Java version in CI and locally via dependency lock output.
• Enable gRPC channel logging to observe the selected load-balancing policy at channel creation.
• Run a small test with two local server ports and log which subchannel receives RPCs with and without the explicit policy.

One diagnostic detail that changes the recommendation: are you using a name resolver such as DNS or xDS that provides a service config for the target? If yes, the service config can override defaultLoadBalancingPolicy, and the policy must be set in the service config rather than only on the builder.