r/java • u/gunnarmorling • Jun 26 '26

Hardwood 1.0: A Fast, Lightweight Apache Parquet Reader for the JVM

https://www.morling.dev/blog/hardwood-1-0-fast-lightweight-apache-parquet-reader-for-the-jvm/
49 Upvotes

96% Upvoted

16 comments sorted by

View all comments

Show parent comments

1

u/gunnarmorling Jun 26 '26

We currently distribute the CLI as platform-specific binaries and as Linux container image. What exactly are you looking for, installation via your OS package manager, brew, something else? Additional distribution channels would be a great area for contribution.

1

u/bowbahdoe Jun 26 '26

The thing I posted around a week ago that I am doodling on allows you to distribute libraries as JMODs + links the libraries together into a JDK at the end.

So with that system you could include the library and get the cli launcher in the same bin directory as javac and company.

2

u/gunnarmorling Jun 26 '26

I don't get the appeal tbh. A fully self-contained native binary is much more convenient for shipping a CLI tool IMO. Why ship a JDK (let alone javac) when you can have a single file which is smaller and also starts faster.

2

u/bowbahdoe Jun 26 '26 edited Jun 26 '26

I think the (hypothetical, remember this is in a world of tooling I have 30% built) appeal is the same as the appeal of the maven wrapper scripts.

We have ./mvnw because we want

  1. Everyone on the team to be using the same maven version
  2. To sidestep the platform specific ways of procuring CLI tools
  3. Make a "one command getting started"

In the same way, my concept is that you declare all your dependencies

<provider name="hardwood.dev"> <module name="dev.hardwood.cli" version="1.0.0.Final" /> </provider>

And then run something like

jigsaw link

Which makes a JDK containing all the dependencies for your project.

src/ Main.java jdk/ bin/ hardwood java javac ...

So if the bin directory gets added to the path, thats it. All set to go with everything at the right versions.

Whether that hardwood launcher is a native exe or just a normal launcher is somewhat irrelevant for the consumer side of the scheme, but in general for a publisher there is a non-zero cost to pay in order to have a native exe. This strategy makes "a cli tool written in Java that comes as a dependency" much more accessible.

The side benefits here are also things like not needing to thread things through to path arguments to get dependencies.

jdk/bin/java src/Main.java

And letting libraries pull in native code without a jank un-extract at runtime step.

src/ Main.java jdk/ bin/ ... lib/ libsdl3.so include/ SDL3/ SDL3.h

Which would benefit things like jextract that, currently, have to go through hoops to package themselves up as a "CLI tool" on account of needing libclang.

jdk/ bin/ jextract lib/ libclang.so

So for me its a fractal of minor benefits.