Native rewrite readiness
Loading evidence…Original native targets and compatibility evidence. Additional application results are tracked separately below.
Capability evidence and compatibility boundaries
Accepted native contracts and scope boundaries
Accepted native contracts do not add Java agreement passes. Original pending methods, Java errors and unsupported cases remain in the comparisons below.
Strict comparison index
Loading the completion model…
An index of tracked targets, not a time estimate. Stale evidence cannot establish completion.
Targets, remaining gaps & calculation
This index combines demonstrated feature coverage, behavioral agreement, performance and current evidence. It is not a percentage of remaining engineering effort or a finish-date estimate.
Each feature area has equal influence within feature coverage. For behavior and performance, the weakest measured check in each family determines that family’s progress. Faster cases cannot offset a slower case, and performance credit stops at the target. Stale results retain their last measured contribution; they cannot establish completion.
100% requires all tracked targets and current successful verification. These bounded checks do not establish universal Timefold equivalence.
Community test coverage
Passing Rust adaptations / discovered upstream test methods
A method counts as passing only when its adapted Rust assertions pass. Parameterized and inherited JUnit invocations are not expanded. How this is measured
Where the rewrite stands
Choose a subsystem to explore its testsScore types
Each square is one test method. Colors indicate the latest result.
Tests by origin
Upstream adaptations, additional native checks and external application regressions.
| Origin | Passing / recorded | Other results |
|---|
Real-world use cases
Two anonymized application workloads with independent score checks. These additional tests earn no upstream Timefold method credit.
| Workload | Rust streams | Java streams | Rust incremental | Java incremental | Rust / Java streams |
|---|
Application test results, source and scoring limits
Throughput is separate from solution quality. These models lack whole keep-together moves, and the runtimes use different random generators and hard-score annealing behavior. The larger use case can remain infeasible. Passing score checks does not establish Java performance parity.
The published snapshot retains numeric outcomes, scores, seeds and evidence hashes. Raw logs, commands, local paths and application identities are omitted; the local report retains the original provenance. Application workloads are outside the original 109 timing targets and strict comparison index.
Aggregate collectors vs. the original
Checked sums, sorted sets and merged maps: replacement, restoration and full observation.
Ratios compare observed median times (Java ÷ Rust). Both runtimes include full result copying and validation. Differences near 1× may be noise.
Consecutive sequences vs. the original
Collector replacement, inverse update and complete result observation.
Ratios compare observed median times (Java ÷ Rust). Both runtimes include full result copying and validation. Differences near 1× may be noise.
Concurrent shadow updates vs. the original
Shared start times: cached derived values, cycles and trial undo.
Ratios compare observed median times (Java ÷ Rust). Both runtimes include validation, with different framework costs. Differences near 1× may be noise.
Pillar transactions vs. the original
Supplied groups: move construction, application, state checks and undo.
Ratios compare observed median times (Java ÷ Rust). Both runtimes include validation, with different framework costs. Differences near 1× may be noise.
Incremental streams vs. the original
Indexed joins and grouped scores, with solution quality beside every timing.
Ratios compare observed median times (Java ÷ Rust). Compare times together with feasibility and score; differences near 1× may be noise.
Construction vs. the original
Sequential, pooled and cycling value construction, with quality beside every timing.
Ratios compare observed median times (Java ÷ Rust). Compare times together with feasibility and score; differences near 1× may be noise.
Repair vs. the original
Half-group and whole-group ruin-and-recreate, with quality beside every timing.
Ratios compare observed median times (Java ÷ Rust). Compare times together with feasibility and score; differences near 1× may be noise.
List repair vs. the original
Required and optional lists with bounded ruin-and-recreate, with quality beside every timing.
Ratios compare observed median times (Java ÷ Rust). Compare times together with feasibility and score; differences near 1× may be noise.
Heuristic search vs. the original
Matched step budgets with solution quality beside every timing.
Ratios compare observed median times (Java ÷ Rust). Compare times together with feasibility and score; differences near 1× may be noise.
List solving vs. the original
Routing construction and local search, with solution quality beside every timing.
Ratios compare observed median times (Java ÷ Rust). Compare times together with feasibility and score; differences near 1× may be noise.
Cyclic k-opt vs. the original
One complete route: compare Rust window and sampled search with Java.
Ratios compare median times (Java ÷ Rust). Compare final quality first; sampling and work differ.
Exact search vs. the original
Same workload, same inputs, independently measured runtimes.
Ratios compare observed median times (Java ÷ Rust). Differences near 1× may be measurement noise.
Mixed planning vs. the original
Joint depot choices and customer routes, scored independently.
Compare final quality first. Dense and Stream comparisons share the measured Java reference; move selection and work differ.
Rust vs. the original
Same workload, same inputs, independently measured runtimes.
Ratios compare observed median times (Java ÷ Rust). Differences near 1× may be measurement noise.
Beyond the adapted tests
Measurement notes & reproducibility
What the percentage means
The denominator includes pending and explicitly excluded methods. Exclusions stay visible so the scope cannot silently inflate coverage. A passing adaptation is evidence for that method’s assertions, not a claim that the original JUnit suite runs against Rust.
Keeping results current
The page reloads saved results every 15 seconds; it does not run tests in your browser. Rust checks regenerate this report. Changes to measured sources mark earlier comparisons stale. The timestamp is the last report generation time.
bash scripts/check.shpython3 scripts/differential_scores.pypython3 scripts/benchmark_scores.pypython3 scripts/differential_solver.pypython3 scripts/differential_lists.pypython3 scripts/benchmark_solver.pypython3 scripts/benchmark_lists.pypython3 scripts/benchmark_kopt.pypython3 scripts/differential_streams.pypython3 scripts/benchmark_streams.pypython3 scripts/benchmark_construction.pypython3 scripts/benchmark_heuristics.pypython3 scripts/benchmark_aggregates.pypython3 scripts/benchmark_sequences.pypython3 scripts/benchmark_concurrent.pypython3 scripts/benchmark_pillars.pypython3 scripts/compat_report.py