Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add Apache Parquet format backend (`jackson-dataformat-parquet`)

Open
  • Is something wrong?
#766 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
java
Domain
backend, data-engineering

Research direction

No repository files, tests, or entry points are identified. Start by reviewing the parquet-java APIs and the prior art linked in the issue, then determine the scope of a Jackson backend. Done would require a bidirectional JsonFactory-level parser/generator plus databind and tree-model access under ObjectMapper, with dependency size considered.

Written by the indexing model from the issue text.

Description

Apache Parquet has become the de-facto interchange format for analytical/columnar data (Spark, Trino, Athena, DuckDB, Arrow, Iceberg/Delta table formats all read and write it).

Today, JVM applications that want to produce or consume Parquet go through the parquet-java libraries directly (org.apache.parquet:parquet-hadoop and friends), which means hand-writing WriteSupport/ReadSupport plumbing or converting through another object model (parquet-avro, parquet-protobuf). Point solutions exist for narrow slices (see prior art below), but there is no first-class Jackson backend: no JsonFactory-level parser/generator pair giving bidirectional streaming, databind (POJOs, Maps) and tree-model (JsonNode) access under the ObjectMapper programming model applications already use for JSON, CBOR, Avro, etc.

Additionally, we've internally observed that adding Hadoop as a dependency ends up blowing the dependencies' size, forcing a lot of teams to drop AWS Lambdas (or using containerised lambdas)

A jackson-dataformat-parquet backend would close that gap: the same ObjectMapper
programming model, applied to the dominant analytics file format.

Prior art

  • https://github.com/getyourguide/parquet-json — Parquet WriteSupport driven by Jackson JsonNode:
    overlaps the write path proposed here (no read path, and no JsonFactory-level
    parser/generator or databind integration)
  • https://github.com/jerolba/parquet-carpet — Java-records read/write binding over parquet-java,
    demonstrating demand for a friendlier binding layer (records only; not a general
    Jackson backend)
  • parquet-avro in parquet-java itself — the "bind through another object model"
    pattern this module would generalize to Jackson's
  • Searched this tracker, jackson-future-ideas and the org: no existing
    Parquet request (only a passing mention in #9).
Dominant language
Java
Stars
348
Forks
159
Avg merge
1d 1h
Merged PRs (30d)
44

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from FasterXML/jackson-dataformats-binary

All issues in FasterXML/jackson-dataformats-binary

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.