Swapping TheAlgorithms-Java implementations behind an existing service API without dropping in-flight requests

Direct answer

For the described service, a thin adapter/facade in front of the static algorithm calls is safer than a package-level swap alone. A package-level swap with shadowed class names is not sufficient on a single JVM classpath without shading or classloader isolation, because the JVM resolves a fully qualified class name once per classloader. There is no documented versioned-coexistence pattern in TheAlgorithms-Java in model knowledge; coexistence of two JAR versions is a general Java classpath problem, not a library feature. Concurrent stress-test thresholds cannot be set from library documentation; they must be derived from your own baseline.

Confirmed facts vs likely explanation

What can be confirmed from model knowledge

TheAlgorithms-Java is distributed as a single JAR with no published versioned API or side-by-side variant mechanism. Two versions with identical package and class names will clash on a shared classpath. Shading/relocation with tools such as Maven Shade or Gradle Shadow is the standard Java technique to give two versions different package names so they can coexist.

What is assumed from the question

The premise that the library's data structures and algorithm implementations are effectively immutable and stateless, and that old and new classes are safe to run side by side under concurrent load, is taken as given here. Generic type erasure limits compile-time guarantees when legacy and modernized variants coexist; that risk is at your integration boundary, not inside the library.

Steps needed for this case

1. Introduce a narrow adapter facade for each algorithm family you call statically. The facade owns the call site and delegates to a selected implementation. This keeps the service API unchanged and gives a runtime selection point.
2. If you need both versions on the same JVM at the same time, relocate one version's packages via shading so the two sets of classes have distinct fully qualified names. Audit any reflection, serialization, or configuration that references fully qualified names, as shading changes them.
3. Keep the adapter stateless and avoid shared mutable instances. If a future version introduces mutable state, the adapter must not share a single instance across requests.
4. Replay identical inputs through both variants and compare output checksums in your test harness. A mismatch is a regression and blocks rollout.
5. Run a staging load test with both variants reachable via the adapter, and compare latency percentiles, throughput and GC behavior against a baseline run with only the legacy path.

One missing diagnostic that changes the recommendation: what is the current production baseline for p99 latency and sustained requests per second for the algorithm paths, and can you change the routing flag without a JVM restart? Without a baseline, numeric stress thresholds cannot be set responsibly, and the ability to toggle routing at runtime determines whether an adapter can be used for incremental traffic shifting or only for a redeploy cut-over.