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

A small Java service currently calls sorting and graph utilities from TheAlgorithms-Java directly by class name. The goal is to migrate to newer versions of those algorithm classes incrementally, while the service keeps handling concurrent requests with no observable downtime or changed outputs.

The documented behavior that matters here is that the library's data structures and algorithm implementations are effectively immutable and stateless, so old and new classes should be safe to run side by side under concurrent load. The uncertainty is at the integration boundary: the service's own API layer calls the algorithm classes statically, and generic type erasure in some implementations limits compile-time guarantees when legacy and modernized variants coexist on the classpath.

A test harness that replays identical inputs against both versions and compares output checksums is planned, but the rollout strategy itself is undecided.

Given these constraints:

• Should the migration introduce an interface or adapter layer in front of the static algorithm calls, or is a package-level swap with shadowed class names sufficient for a small application?
• Is there a documented pattern in TheAlgorithms-Java for versioned coexistence of two algorithm variants, or must both JAR versions be shaded to avoid classpath conflicts?
• What concurrent stress-test thresholds are reasonable to confirm that running both variants simultaneously does not introduce contention or latency spikes?