I’m about the same. I’ve had one Java project going for over 10 years. It’s a collection of utilities that I use for work everyday that has grown substantially over the years. It is a CLI program that runs in my Mac, Linux servers and Linux HPC clusters. It is built with a fat-JAR concatenated to a shell stub in front that makes it effectively a single-file install. I also wrote a complete library for defining CLI programs. It is pretty easy to use, but it relies on reflection and annotations, so Graal has been difficult to get working (or was the last time I tried).

All of that to say, I’m also familiar with the problem.

For the past 3-4 years I’ve reached more for Go to my new CLI projects. Small differences in installed Java versions across clusters can be a problem, but for me the biggest issue is dealing with JVM arguments. I writing code for working with genomics data files. Sometimes these are large, and sometimes they are small. And I hate having to tell both my job scheduler (SLURM mainly these days) and the JVM how much memory to use.

This isn’t a problem in Go. So, that’s the language I gravitate to these days.

> Java cli is a solution looking for a problem

That's a great way of putting it. I'm a Java developer also; I'm most comfortable with Java and, dare I say, I like Java. But Java would be far down the list of tools I'd use to make a CL program.

Same here. Was using Java in the alpha/beta/gamma days. Have built a lot with it. Would not use it for command line tooling by default, only if it happened to be the simplest option (like maybe a library or something does nearly everything needed).