// the find
lemire/externalsortinginjava
External-Memory Sorting in Java
An external-memory sorter for files too large to hold in RAM. It splits the input into memory-sized batches, sorts each batch, writes the sorted batches to temp files, then k-way merges them into the output. It is aimed at Java developers sorting large line-oriented or CSV files, and its use in Apache Beam, Jackrabbit Oak and Spotify scio is the strongest evidence that it works in practice.
The CSV path does more than sort lines. CsvSortOptions takes a Comparator<CSVRecord>, handles numHeader and skipHeader, and returns header rows through a list, so headers can be kept in the output without being sorted. Batch sizing works from a memory budget and per-record size estimators (StringSizeEstimator, SizeEstimator) rather than a fixed line count, so batches follow actual byte cost on wide or uneven rows. The tests cover awkward inputs: semicolon and tab separators, non-Latin text, and a regression fixture named issue44.csv that points at a reported bug. The plain-text API is two calls, sortInBatch and mergeSortedFiles, and the repo ships both a CI workflow and a release workflow.
The memory budget is a guess. The CSV example passes estimateAvailableMemory(), and the README gives no peak-heap or throughput numbers, so you will be tuning the budget by trial on your own data. The README does not say where temp files go, how many are left behind after a failure, or whether the caller has to clean them up, which matters when disk is the constraint. The build section is stale: it says to install Maven 2 and that mvn install requires signing, which will confuse a new contributor. The Maven snippet also uses an open-ended [0.6.0,) range, so consumers pick up whatever ships next without review. The plain-text API treats each line as one record, so multi-line quoted CSV fields only work through CsvExternalSort, and the README sample does not warn about this.