Legacy modernization · Strust v1 paper
Strust: comparing COBOL and Java
The Strust v1 paper describes comparing a COBOL program with its Java replacement under a shared test contract. It includes a ten-case historical ledger and a proposed verification architecture; the preserved records do not establish production accuracy or scale.
The question
How can we check that a COBOL program and its Java replacement behave the same?
What I worked on
I built Strust around a testing problem: run a COBOL reference and a Java candidate on controlled inputs, capture their observable behavior, and compare the results under an explicit contract.
The v1 paper describes the proposed contract, execution setup, comparison policy, and evidence to retain. It distinguishes MATCH, DIVERGE, and INCONCLUSIVE, and explains how smaller checks could be combined into longer workflows.
What I found
The worked example reconstructs a ten-case historical ledger, including two disagreement cases involving rounding and character encoding. The source programs and raw traces were not preserved, so the recorded judgments cannot be independently replayed.
The paper’s small-sample analysis does not establish an advantage over its comparison rules. The larger verification architecture remains a proposal for subsequent evaluation.
What this does and does not tell us
The ledger records a small, manually chosen set of cases. It does not measure production accuracy, enterprise scale, or the behavior of a current Strust release.
The proposed architecture requires separate evaluation with executable subjects, raw paired observations, and fixed runtime and comparison policies. The historical ledger does not validate that design.
A follow-up should preserve executable reference and candidate programs, freeze the comparison policy, and evaluate new blinded cases with raw traces and runtime identities retained.
Read the paper
STRUST-v1: A Small-Sample Evidence Audit and Unvalidated Verification-Slice Proposal