Choose Java-to-Clojure migration candidates with clear inputs, observable outputs, useful tests, limited framework coupling, and a boundary that can be wrapped before it is rewritten.
Not all Java code is an equally good first migration target. The best starting points usually look like pure-ish libraries: code that transforms data, validates inputs, or implements domain rules with clear inputs and outputs.
This section helps you choose candidates that keep risk low: components with good test coverage, stable behavior, and a clean boundary you can wrap with a thin Clojure adapter. Avoid migrating the most framework-entangled or latency-critical parts first unless you have a strong reason.
| Candidate signal | Migration implication |
|---|---|
| Clear input and output values | Good first target because behavior can be captured with fixtures and compared after the rewrite. |
| Heavy framework lifecycle coupling | Delay or wrap first; migrating it early usually creates avoidable integration risk. |
| Weak tests but stable behavior | Add characterization tests before writing Clojure code. |
| Performance-critical hot path | Measure first and migrate only with a benchmark and rollback plan. |