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

Pure Java NIO LocalInputFile Implementation

Open
#3,028 1 comment 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
java
Domain
backend

Research direction

Read parquet-common/src/main/java/org/apache/parquet/io/LocalInputFile.java and compare it with the NioInputFile implementation linked in the issue. Check how LocalOutputFile uses Java NIO, then clarify whether completion means updating LocalInputFile or adding a separate implementation that works with alternate FileSystem providers.

Written by the indexing model from the issue text.

Description

Type: enhancement
Describe the enhancement requested

Hi there!

In an effort to reduce our coupling to Hadoop, and slim down our shaded Jar sizes, we transitioned all our Parquet reading / writing to using the non-Hadoop public interfaces. We leveraged Java NIO interfaces for reading / writing I/O, as detailed in this blog post here: https://blakesmith.me/2024/10/05/how-to-use-parquet-java-without-hadoop.html

The problem we hit: The current LocalInputFile implementation falls back to Path#toFile and RandomAccessFile calls for I/O operations. Once we plug in other java.nio.file.FileSystem implementations (Such as using AWS' Java NIO SPI implementation), the LocalInputFile implementation doesn't work anymore.

We've created our own implementation of LocalInputFile called NioInputFile, that implements the interface, but exclusively using Java NIO operations, instead of falling back to older Java file APIs. You can see the code in the above linked blog post, and also in this gist here: https://gist.github.com/blakesmith/5c08a2504c08c96f9fb62658ec6c9b28

A few questions, before I start sending patches:

  1. Is this alternative implementation something that folks are interested in incorporating upstream into Parquet itself?
  2. If so, would we prefer to update LocalInputFile, or add NioInputFile as another implementation of LocalInputFile? Note that in our case, we're doing buffered I/O to S3 with this implementation, so it's not technically a "local" file, either way, just one that talks to the Java NIO abstractions.

Of note is that LocalOutputFile is working just fine with Java NIO operations, even when we're doing remote S3 I/O.

Thanks you so much! Parquet has been transformative for us, and we're excited to help drive more adoption however we can.

Component(s)

Core

Dominant language
Java
Stars
3.1k
Forks
1.6k
Avg merge
6d 16h
Merged PRs (30d)
36

Contributor guide

No contributing guide indexed for this repository

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 apache/parquet-java

All issues in apache/parquet-java

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.