// the find
BerryWorksSoftware/edireader
EDIReader is a flexible and lightweight EDI parser, written in pure Java with many integration options. It has handled millions of transactions in a wide variety of products, services, industries, platforms, and custom integrations. Used in BerryWave EDI API and BerryWave Python EDI SDK.
EDIReader is a pure-Java streaming parser for X12, EDIFACT, and HL7 that reports EDI content through standard SAX events, first released in 2004. It is the parsing core under BerryWorks' commercial BerryWave EDI API and Python SDK, and it suits Java teams who want to process large EDI files without building an in-memory tree. It parses; it does not validate, write, or convert to JSON.
Memory does not grow with input size, because the parser emits SAX events instead of building a DOM, which is the main reason to pick this over a tree-based library. The only required runtime dependency is SLF4J, and the README says it runs on Android as well as standard JVMs, which keeps the footprint small for code that gets embedded in other products. Error messages say where the problem is: a bad UNT count reports the expected and actual values, the segment index, and the field number, and an option lets parsing continue past recoverable errors, which matters when a trading partner sends slightly broken files. One parser covers X12, EDIFACT, and HL7, auto-detects the syntax delimiters, and produces 997/999 and CONTRL acknowledgments as a by-product of parsing, so most inbound pipelines skip a separate acknowledgment step.
The default license is GPLv3, so a closed-source product that embeds this parser needs the commercial license from BerryWorks, which the README mentions only in passing. Check that before building on it, not after. The open-source scope is narrow: EDI writing, schema validation and compliance checking, element annotations, and JSON output all live in the commercial Framework or its Community Edition, so anyone expecting EDI in and JSON out from this repo alone will need a second dependency. Segment-loop awareness depends on plugins, and the plugin set covers a fixed list of transaction sets (834, 835, 837, 810, 850, a few EDIFACT messages), so anything outside that list means writing your own loop rules. The README gives no throughput numbers; 'handled millions of transactions' and 'high performance' are asserted, and the benchmark package is not described or linked. The quick-start also opens a FileReader without closing it or setting a charset, and it is the first code many people will copy.