I casually watch a lot of forums related to Java: IRC, of course, and Discord, and Slack, and Reddit. On Reddit, on r/java, there’re some occasionally quite interesting projects offered for consideration; they’re usually pet projects for the authors, and that’s healthy and useful for everyone.
However, there’s also a low hum of … tooling. Two really interesting projects showed up recently, for example, that avoided standard tooling: one used PowerShell, another used a bash script to build.
Both of these projects work. They both generated the expected output; the bash script actually went way above and beyond (replicating what a good Gradle script might do), downloading a JVM and manually grabbing the dependencies via wget, then manually calling javac and jlink in a manner that would make Mark Reinhold proud, then building an AppImage for x86_64 using the platform-appropriate tools.
The Reddit discussion on that latter one did not go especially well, however, because the tooling discussion ended up front and center, with what looks like a lot of hurt feelings.
“This looks like a novice project” was the import of one comment, with another being that the tooling might have helped; that went south quickly. It was not a “novice project.” The author was solving a problem they encountered in their own way, including implementing some X11 protocols in Java. Project infrastructure choices don’t make one a “novice,” especially as an insult.
The thing is, the comment about tooling might be pretty apt. My personal thought about the project, based on the discussion, was “why not tooling?” Are the tools insufficient? The project owner built an x86_64 image specifically; that may suit their purposes (and as the primary project consumer, their purposes are most important) but what would it have taken to build an ARM image? Would the tooling have been sufficient for that?
It might not have been. The way I see it, there’re a few reasons the tooling would be avoided:
- Lack of awareness. The author said they knew about the tooling and avoided it, but maybe they didn’t check to see if the tooling could create AppImages.
- Lack of functionality. Maybe they did check, but the functionality wasn’t there, or wasn’t sufficient.
- Lack of documentation. Maybe the functionality was there, but was documented poorly enough that it was easier to do it the straightforward way instead. (Is that OSGi I hear weeping in the distance? It just might be.)
- Personal preference. Maybe the OP knew about the tooling and just didn’t care.
If personal preference is involved, well, the discussion’s over. At that point, it’s like arguing that the author’s favorite number should clearly be 18 instead of 11. It’s their project, not anyone else’s, and if they make a decision based on their preference, that’s their right and power.
But the other options, well, those are things that we as a community might be able to help. And I think we should consider helping, even if the “help” might not apply to this specific circumstance.
So: We can help, but we need to consider:
- How we approach the help
- What use cases are poorly served by the tooling today
- How are we evangelizing our practices, and why
- What would “better” look like?
- Do we even understand each other to understand why people choose different approaches?
These aren’t necessarily idle musings. We want Java to remain vital, we want to do what we can to establish common practices so we can help each other, we want to make sure that we’re not presenting barriers to people whose skills we want in our ecosystem; it’d be nice if we could offer commentary without sneering (and, to be fair, accept commentary without bristling.)
Let’s all be kind to each other, an effort that would make us more effective as well.