Maybe some of the old beliefs regarding startup time etc are no longer valid. Maybe the programming model isn’t as verbose as it used to be. But I don’t want to distribute a 200MB+ binary. I have colleagues who tell me that c# scripting is so awesome. One only needs .NET installed or use AOT or whatever. Sorry but Go and Rust and good forgive a python script is smaller and mostly easier to read and write then most stuff I seen other languages shoehorning into. I have nothing against Java but it isn’t the right hammer for this problem. At least for me. And I wish people wouldn’t constantly strive for the single language for every problem mindset. Yes in a Java shop it might make more sense to write cli tools and scripts also in Java. But that doesn’t mean it is the most effective toolchain in the long run.
2026: The Year of Java in the Terminal?
11–20 of 191 posts
Re: 2026: The Year of Java in the Terminal?
#12Go?
Re: 2026: The Year of Java in the Terminal?
#13> Try a GraalVM native image. Milliseconds. Gone.
Try building a GraalVM native image. Minutes gone.
Re: 2026: The Year of Java in the Terminal?
#14The article makes no compelling points to me as an avid user of these applications.
I would rather shove ice picks covered in lemon juice than provide Java or Ellison anymore room in the digital ecosystem. And I’m not talking politics here wrt Ellison, just awful
Re: 2026: The Year of Java in the Terminal?
#15I've been a Java developer for twenty years. I've used it for everything front front end to distributed systems. I've built gradle plug-ins and clips with JAVA. I have every shortcut in intellij memorized.
Even with all this it takes me substantially less time to get go, python, or ts working as a cli. Java cli is a solution looking for a problem
Re: 2026: The Year of Java in the Terminal?
#16Java startup time shouldn't really be an issue with a terminal program. I have written some pretty complex Java and Rust and C++ terminal programs, they are basically indistinguishable on run time. The reason Java starts up slow for most people is that they are running webapps with Spring and 50 dependencies and loading Tomcat, not because they are just booting a JVM and running through some functions. Getting AoT co…
+1 on the AOT compilation. I was surprised there is still a noticeable difference between Graal and a "standard" JVM even if you have eliminated all the other cruft. Both are practically usable, no question, but the latter really felt "instant".
I was amazed when I tried Graal the first time, but also had to think that this is probably what C/C++ or Rust devs just see as "normal".
Re: 2026: The Year of Java in the Terminal?
#17The moment you introduce the jvm, is the moment people flee. Graal would be needed and then your binaries would be huge. No thanks. Go is much simpler. Rust is much smaller. Java can go die in the office storage closet.
Go and "simpler"? Really?
C is simpler, Python is simpler, but Go?
Re: 2026: The Year of Java in the Terminal?
#18Java will never become a player in CLI tooling until build packaging becomes first class. Go, Rust, and other languages are so common because their build tooling is dead simple. You can easily get a single file distributable in a single command. go build, cargo build, dotnet publish —-self-contained.
Java on the other hand makes it impossible to get a single distributable. There is no way to get your jar + the vm into a binary. You could use graal native image, but build times are super slow, use too many resources, and it’s non-trivial to get working.
Build tooling in the Java ecosystem just isn’t good enough.
Re: 2026: The Year of Java in the Terminal?
#19> Try a GraalVM native image. Milliseconds. Gone. Try building a GraalVM native image. Minutes gone.
More gigabytes of ram than your machine has will be gone too.
Re: 2026: The Year of Java in the Terminal?
#20Very clearly written by AI. Java in the terminal sounds awful. Programming Java is awful. No thank you.
Can you back up your claim the post is written by AI?