Java CSV Libraries in 2026: uniVocity vs Commons CSV vs Jackson CSV — Which Parser Should You Use?

Your Java app will eventually parse a CSV file — it is the universal interchange format for banks, government datasets, e-commerce exports, and pretty much every legacy system still running on mainframes. And that is exactly where naive parsing bites: a 2 GB CSV from a data vendor can turn a 30-second batch job into a 40-minute OOM killer, or silently corrupt rows when a field contains a newline or a quoted comma. The three serious options — uniVocity parsers, Apache Commons CSV, and Jackson CSV — take completely different trade-offs on speed, memory, and API style. This guide compares them with live repository data and real code so you can pick the right one before your next data migration deadline.

TL;DR / Quick Verdict

• Maximum throughput on huge files → uniVocity parsers (935 stars). The fastest general-purpose parser for Java, with row/column-level processing that keeps memory flat. Its Achilles heel: the GitHub repo has not seen a push since 2024-08 — the project is stable but effectively in maintenance mode.
• Boring, reliable, dependency-light → Apache Commons CSV (415 stars). Actively maintained (last push 2026-08-25), Apache-2.0, and the safest choice for standard CSV/TSV/Delimited formats. Slower than uniVocity on huge inputs but completely predictable.
• Streaming + JSON-style databinding → Jackson CSV (part of jackson-dataformats-text, 454 stars). If your team already lives in the Jackson ecosystem, this gives you the same ObjectMapper mental model for CSV, with excellent incremental parsing for arbitrarily large streams.
• Recommendation: parse with Commons CSV unless you have measured a performance problem; switch to uniVocity when you have one, and reach for Jackson CSV when you want CSV to feel like JSON.

Quick Comparison Table

Use Case Decision Matrix

uniVocity parsers — The Speed King (With a Caveat)

uniVocity is a suite of parsers (CSV, TSV, fixed-width, and more) built around one idea: parsing should not be the bottleneck of your ETL pipeline. Its CsvParser gives you row-by-row callbacks, which keeps memory usage constant no matter how large the input is — the classic mistake with naive parsers is calling parseAll() and materializing the entire file into a List<String[]>, which is exactly what uniVocity lets you avoid.

The GitHub repo shows 935 stars and a mature feature set (automatic bean mapping, header processing, format detection, and even a dedicated CsvWriter). The honest caveat is the maintenance cadence: the last push was 2024-08-17 — the project is not abandoned, but new releases are rare, and the parser tutorial lives on the project website rather than in the README. For a stable dependency that you pin and forget, that is fine; for teams expecting active bug-fix cycles, it is a consideration.

The core usage pattern is straightforward:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

import com.univocity.parsers.csv.CsvParser;
import com.univocity.parsers.csv.CsvParserSettings;

CsvParserSettings settings = new CsvParserSettings();
// Read the header row and use it for column-index mapping
settings.setHeaderExtractionEnabled(true);

CsvParser parser = new CsvParser(settings);
parser.beginParsing(new FileReader("data.csv"));

String[] row;
while ((row = parser.parseNext()) != null) {
    // row[0], row[1], ... — process one row at a time, constant memory
}
parser.stopParsing();

Maven:

1
2
3
4
5

<dependency>
  <groupId>com.univocity</groupId>
  <artifactId>univocity-parsers</artifactId>
  <version>2.9.1</version>
</dependency>

Where uniVocity shines is row iteration overhead: its parseNext() loop is consistently faster than the iterator-based approaches of the other two libraries in micro-benchmarks, and the difference grows with row count because it avoids per-record object allocation. If you are processing hundreds of millions of rows, this is the difference between a nightly job and a weekend job.

Apache Commons CSV — The Reliable Workhorse

Apache Commons CSV is what you get when you want the CSV equivalent of a Swiss Army knife: nothing fancy, everything solid, Apache-2.0 licensed, and maintained by the Apache Commons project with a very predictable release cadence (current stable 1.14.1, last GitHub push 2026-08-25). Its design goal is a simple interface for reading and writing CSV files of various types — and it delivers exactly that in a single small jar.

The API is built around CSVFormat, which encodes the dialect (delimiter, quote character, escape, record separator, header), and CSVParser/CSVPrinter for reading and writing:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

import org.apache.commons.csv.CSVFormat;
import org.apache.commons.csv.CSVParser;
import org.apache.commons.csv.CSVRecord;
import java.io.Reader;
import java.nio.file.Files;
import java.nio.file.Paths;

try (Reader reader = Files.newBufferedReader(Paths.get("data.csv"));
     CSVParser parser = CSVFormat.DEFAULT.builder()
         .setHeader()
         .setSkipHeaderRecord(true)
         .get().parse(reader)) {

    for (CSVRecord record : parser) {
        String id = record.get("id");        // header-based access
        String name = record.get("name");
        System.out.println(id + ": " + name);
    }
}

Writing is equally clean — CSVPrinter handles quoting and escaping for you:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

import org.apache.commons.csv.CSVFormat;
import org.apache.commons.csv.CSVPrinter;
import java.io.Writer;
import java.nio.file.Files;
import java.nio.file.Paths;

try (Writer writer = Files.newBufferedWriter(Paths.get("out.csv"));
     CSVPrinter printer = new CSVPrinter(writer, CSVFormat.DEFAULT.builder()
         .setHeader("id", "name", "email").get())) {

    printer.printRecord(1, "Ada Lovelace", "ada@example.com");
    printer.printRecord(2, "Grace Hopper", "grace@example.com");
}

Maven:

1
2
3
4
5

<dependency>
  <groupId>org.apache.commons</groupId>
  <artifactId>commons-csv</artifactId>
  <version>1.14.1</version>
</dependency>

The trade-offs: Commons CSV is not the fastest parser on huge files (its iterator creates a CSVRecord per row), and its format-builder API has a learning curve for exotic dialects. But for 95% of real-world CSVs — including the messy ones with quoted commas and embedded newlines — it parses correctly and predictably. That correctness matters more than raw speed for most teams, which is why Commons CSV remains the default recommendation in our stack.

Jackson CSV — CSV That Thinks It’s JSON

Jackson CSV is the jackson-dataformat-csv module of the FasterXML umbrella project. If you already use Jackson for JSON, this is the lowest-friction way to add CSV support: the same CsvMapper (a subclass of ObjectMapper) drives both, and you get streaming readValues() for arbitrarily large files with the same mental model as readValues() for JSON arrays.

The repository (jackson-dataformats-text, 454 stars) hosts the CSV, Properties, TOML, and YAML backends, with active development on the 2.18/2.19 lines (last push 2026-08-24). The killer feature is POJO databinding: define a class, declare a CsvSchema, and rows become typed objects:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

import com.fasterxml.jackson.dataformat.csv.CsvMapper;
import com.fasterxml.jackson.dataformat.csv.CsvSchema;
import java.io.File;
import java.util.List;

public class User {
    public String id;
    public String name;
    public String email;
}

CsvMapper mapper = new CsvMapper();
CsvSchema schema = mapper.schemaFor(User.class).withHeader();

List<User> users = mapper.readerFor(User.class)
    .with(schema)
    .<User>readValues(new File("data.csv"))
    .readAll();

Maven:

1
2
3
4
5

<dependency>
  <groupId>com.fasterxml.jackson.dataformat</groupId>
  <artifactId>jackson-dataformat-csv</artifactId>
  <version>2.18.1</version>
</dependency>

Jackson CSV’s strengths: seamless integration with the Jackson annotation ecosystem (@JsonProperty, @JsonIgnore), streaming reads for huge files, and consistent behavior between CSV and JSON paths. Its weaknesses: the schema API is more abstract than Commons CSV’s format builder (debugging a misconfigured schema takes longer), and it is slower than uniVocity on raw row iteration. It also pulls in the Jackson core jars, which matters if you are trying to keep a utility dependency light.

Pitfalls and Migration Guide

1. Never call parseAll() on files you cannot hold in memory. This is the number one OOM source in real CSV pipelines. uniVocity’s parseNext() loop, Commons CSV’s iterator, and Jackson’s readValues() are all streaming — use them. If you inherited parseAll() code, swap it for the streaming equivalent before the data team hands you a 5 GB export.
2. Header detection must match your actual file. setHeaderExtractionEnabled(true) (uniVocity) and setSkipHeaderRecord(true) (Commons CSV) differ subtly: one consumes the header for mapping, the other skips it as data. Mixing them up silently shifts every column by one — the classic off-by-one that corrupts databases without throwing any error.
3. Quoted fields with embedded newlines break regex-based parsers. Never split on \n or , with regex/String.split(). Real CSVs (especially European address exports) contain newlines inside quoted fields. All three libraries handle this correctly; your hand-rolled splitter does not.
4. Character encoding is a silent data killer. The file says “UTF-8” in the email, but it’s actually Windows-1252 or has a UTF-8 BOM. Always specify the charset when opening the Reader (Files.newBufferedReader(path, StandardCharsets.UTF_8)) — the default platform charset is different on Windows vs Linux and will corrupt accents.
5. CRLF vs LF matters for round-tripping. If you read with one record separator and write with another, downstream Windows tools may double up or merge rows. Set the record separator explicitly in your CSVFormat/settings rather than relying on defaults.
6. uniVocity’s slow release cadence is a supply-chain consideration. The project is stable and battle-tested, but if your security policy requires patches for newly disclosed CVEs within days, an actively-released library (Commons CSV, Jackson) may be a better fit — verify with your scanner of choice, the same way you would vet any pinned dependency.
7. Bean mapping hides column drift. Both uniVocity (BeanProcessor) and Jackson CSV map columns to fields by name; a vendor adding/removing a column fails silently or throws at an obscure point. Add an explicit schema/header assertion in tests — parse a known-good fixture in CI so column drift is caught at build time, not in production.
8. Performance claims need your data. “uniVocity is fastest” holds for wide tables with many short rows; for narrow files with long text fields, the gap narrows. Benchmark with a realistic sample before rewriting a working pipeline purely for speed.

Choosing the Right Parser for Your Pipeline

The three libraries are not really competitors for the same slot — they are three philosophies. Commons CSV is the conservative default: predictable, Apache-governed, and good enough for almost everything. uniVocity is the performance play: you adopt it when you have measured a real bottleneck, and you accept a slower maintenance cadence in exchange for throughput. Jackson CSV is the ecosystem play: teams that serialize everything through Jackson get CSV support with the same annotations and streaming model they already use.

A pragmatic approach used by many production teams: keep Commons CSV as the project-wide default (it is the easiest to hire for and the least surprising), and isolate any truly hot parse path behind an interface so you can swap in uniVocity later without touching business code. Our Go CSV and data processing guide covers the command-line side of the same problem, and if you are processing spreadsheets rather than flat files, the spreadsheet generation libraries comparison shows where CSV ends and Excel begins.

FAQ

Which Java CSV library is the fastest?

uniVocity parsers is generally the fastest for row-by-row iteration on large files, thanks to low per-row allocation overhead. Apache Commons CSV and Jackson CSV are both fast enough for typical workloads; the difference only becomes significant in the millions-of-rows range. Always benchmark with your own file shape before choosing.

Is Apache Commons CSV still maintained in 2026?

Yes. Apache Commons CSV 1.14.1 is the current stable release, the GitHub repository had its last push on 2026-08-25, and releases follow the regular Apache Commons cadence. It is the most actively maintained of the three libraries in this comparison.

Can Jackson CSV parse CSV into Java objects automatically?

Yes. Jackson CSV uses CsvSchema + ObjectMapper-style databinding: define a POJO, create a schema with mapper.schemaFor(YourClass.class).withHeader(), and read rows directly into typed objects. It supports the same Jackson annotations you use for JSON.

How do I read a very large CSV without running out of memory?

Use streaming APIs: uniVocity’s beginParsing()/parseNext(), Commons CSV’s parser iterator, or Jackson’s readValues(). Avoid parseAll()/readAll() on files larger than available heap. Processing rows one at a time keeps memory usage constant regardless of file size.

Does uniVocity support TSV and fixed-width formats?

Yes. uniVocity parsers include dedicated TSV and fixed-width parsers (TsvParser, FixedWidthParser) plus a general-purpose format detection, all with the same row/column API as its CSV parser.

Why does my CSV parser skip the first row?

You are double-handling the header. With setHeaderExtractionEnabled(true) (uniVocity) or setHeader() + setSkipHeaderRecord(true) (Commons CSV), the header is consumed for column names and must not also be processed as data. Pick one behavior and verify with a three-row test file before wiring up real data.

💰 想测试你的市场判断力？我用 Polymarket 做预测市场交易——这是全球最大的预测市场平台，从大选结果到技术监管时间线，什么都可以押注。和赌博不同，这是真正的信息市场：你懂的信息越多，胜率越高。我靠预测技术相关事件的走向已经赚了不少。用我的邀请链接注册：Polymarket.com