A team hits a diamond conflict where two transitive dependencies require incompatible major versions of the same library, and decides to 'force' the whole build onto a single chosen version regardless of what any individual dependency originally declared. What are the risks of this approach, and when would forcing a single version NOT be the right call?

## What forcing actually does **Forcing a dependency version** means explicitly instructing the build tool to disregard its normal conflict-resolution algorithm for a given artifact and always use one specific version everywhere in the graph, no matter what any individual dependency declares. - In **Gradle** this is done via `resolutionStrategy.force(...)` or the stricter `strictly(...)` constraint. - In **Maven** it's typically achieved by declaring the desired version explicitly in the parent POM's `dependencyManagement`, which then overrides whatever transitive versions would otherwise be pulled in. Mechanically, this works exactly as intended: after applying it, there is genuinely only one version of that artifact anywhere on the resolved classpath, eliminating the ambiguity a diamond conflict would otherwise leave to a generic tie-breaking heuristic. The team gets full, deterministic control over exactly which jar ships. ## What forcing does not do What forcing does not do, and what makes it risky, is **verify compatibility**. The build tool's job when you force a version is purely **mechanical substitution** — it does not recompile, re-test, or re-verify that the transitive dependency which originally asked for a different version actually still works correctly against the forced one. If library A was built and tested exclusively against library C version 1.x, and the team forces C to version 3.x because that's what library B needs, nothing in the resolution step checks whether A's calls into C still resolve correctly at 3.x. The diamond conflict doesn't disappear technically — it's just **relocated**: - from "the resolver has to pick a version" - to "the code silently runs against a version nobody verified it against," which, as covered in binary-incompatibility failure modes, tends to surface as a `NoSuchMethodError` or similar linkage failure only once the affected code path actually executes, potentially well after the force was applied and the change shipped. ## The trade-off The trade-off, then, is **determinism and simplicity** on one side against **unverified compatibility risk** on the other. Forcing is cheap to apply — a few lines of build configuration — and it does genuinely solve builds that otherwise fail outright due to a hard resolution conflict (for example, Gradle's `strictly` constraints from two different dependencies that are mutually exclusive, which without intervention fail the build rather than silently picking a winner). But that cheapness is deceptive: the actual cost of verifying the forced version is safe for every consumer gets pushed onto whoever runs the test suite (if it has coverage of the affected code paths) or, worse, onto whoever hits the bug in production if it doesn't. ## When forcing is the wrong call 1. **A genuine breaking API change.** Forcing is clearly the wrong call when the two versions in conflict are separated by a genuine breaking API change with no realistic path to reconcile — for instance, when one branch of the graph needs a pre-1.0 version of a library whose 1.0 release rewrote its entire public API, and the dependency stuck on the old version has no available update. In that situation, forcing either version guarantees breaking one of the two consumers; the actual fix has to happen upstream: updating or patching the lagging dependency to work with the new API, replacing it with an alternative library, or, in JVM environments, physically isolating the two incompatible versions behind separate classloaders — shading/relocating one copy's package names so it no longer collides with the other on the classpath. 2. **A rarely-hit code path.** Forcing is also the wrong tool when the team can't realistically exercise the forced combination end-to-end before shipping — for a library used only on a rarely-hit code path, a forced version with no dedicated regression test is essentially an unverified bet deferred to whichever user happens to trigger that path first. 3. **Pinning around the disagreement.** Finally, forcing a version purely to make a build succeed without investigating why the conflict arose treats a symptom rather than the cause; often the healthier fix is diagnosing which dependency has fallen behind and updating it deliberately (or moving the whole family onto a BOM/platform, as discussed for alignment strategies) rather than pinning around the disagreement indefinitely. ## Where forcing is usually safe, and where it bites A concrete, well-known instance of teams reaching for forcing under pressure is with **logging bridges**; contrast that with a serialization library. For example: | What gets forced | How it tends to turn out | |---|---| | A single SLF4J or Log4j binding version across a large multi-module build when different third-party libraries pull in conflicting logging backends | This usually works safely because logging APIs tend to be intentionally conservative about breaking changes and most callers only touch a small, stable surface of the API | | A data-serialization library like an older Jackson or Gson version across a graph where a newer consumer relies on APIs introduced after the forced version | That's the pattern most likely to produce a silent, deferred production break, precisely because serialization libraries expose a much larger surface area that's more likely to have actually changed between the two conflicting versions |