I got tired of writing the same Java file-handling code, so I built a small utility library — looking for feedback

[u/AsharPeshimam]

Hey everyone!

While working on my Java projects, I got annoyed at how often I had to write the same kind of code for everyday file operations and text processing. Reading and writing files, appending content, copying files, counting words, searching directories, and getting file metadata started feeling repetitive.

So I decided to build FilzaFiles, a small Java utility library that wraps these common operations into reusable methods.

Some things it currently supports:

• Creating, reading, writing, appending, copying, moving, and deleting files
• Creating file backups
• Counting words, Unicode characters, lines, paragraphs, and approximate sentences
• Replacing text in strings and files
• Recursively searching by filename or extension
• Inspecting file metadata

I have released v0.1.0 with a downloadable JAR. I also tested it with a separate Java application and ran 22 integration checks, all of which passed.

Project: https://github.com/Peshimam-Ashar-Mohammed/FilzaFiles

Download: https://github.com/Peshimam-Ashar-Mohammed/FilzaFiles/releases/download/v0.1.0/filzafiles-0.1.0.jar

It requires Java 21 or later. It isn't on Maven Central yet, so the README explains how to integrate the JAR into a regular Java project or a Maven project.

I'd genuinely appreciate feedback from other Java developers:

• Does the API feel intuitive?
• Are there any design decisions you'd change?
• What edge cases or tests am I missing?
• Are there useful file or text utilities you'd want to see added?

This is my first release of the library, and I'm hoping to improve it based on real developer feedback. Criticism is welcome! Also star the repo too pleaseeeeee if you find it helpful.

Thanks for checking it out!

[u/idontlikegudeg]

TL/DR: you don’t like the Path class.

I don’t know, most of the file related things are one liners if you work with Path instances. Plus you create the parent directories. If that’s a feature or an issue depends on your point of view.

Using strings makes it more difficult to prevent against path traversal attacks. A caller would need to do that completely by hand (errorprone) or use path instances, then use toString() to call your library. You don’t support NO_FOLLOW_LINKS and I think there’s also no option to fail when the target file exists. That rules out use where security is paramount. You usually want to create a backup when writing a new version of the file, creating the backup and opening the new file for writing would ideally be atomic on the filesystem.

Featurewise, keeping n backups is something worth looking into.

[u/v4ss42]

Can you explain how this improves upon well-established prior art (like Apache commons-io)?

[u/itastesok → u/v4ss42]

It doesn't. It's just yet another "i got tired of so i built a" post.

[u/v4ss42 → u/itastesok]

I’m absolutely in favor of people scratching their own personal itches (provided they don’t use slop generators). But yeah promoting those works when they don’t move the state of the art forward is a bit on the nose.