Live data from Hacker News

2026: The Year of Java in the Terminal?

xam.dk

101–110 of 191 posts

Re: 2026: The Year of Java in the Terminal?

#101
post #91

But latency. No Java app I have used in 25ish years has ever started in a reasonable amount of time.

> started in a reasonable amount of time

A hasty generalization with a little confirmation bias, perhaps?

    $ time keenwrite.bin --version
    KeenWrite version 3.6.5
    Copyright 2016-2025 White Magic Software, Ltd.

    user 0m0.329s
From Claude:

> It's worth noting this is a common perception about Java, and there's some historical truth to it (especially with Swing desktop applications from the 2000s). However, the absolute statement "no Java app... ever" is the fallacy - it's an overgeneralization from limited personal experience to a universal claim.

Re: 2026: The Year of Java in the Terminal?

#103
post #18

Java 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 int…

> Java on the other hand makes it impossible to get a single distributable. Heh, I find this very amusing and ironic, seeing how Write Once Run Anywhere was a stated goal with Java, that failed miserably.

It was successful for a while. Java applets were once fairly common. But then Flash largely replaced them, and then Html5 killed them flat.

Re: 2026: The Year of Java in the Terminal?

#104

Why? It's not well suited to it - fundamentally the language semantics lead to very large distributions, slow startup and expecting a runtime on the machine. Okay, I hear this can be solved by Graal, but that's a whole piece of its own complexity that you'd never have to worry about with a tool written in something like Go. Python has many similar properties, but at least there I can understand that Python is a 'pret…

Its not necessarily fair to use past experience with programming languages that have been seeing major updates year over year. Java as a command line environment has been pretty painless for me, particularly Saxon. Just need to alias the command to include a path to the jre binary.

Python has been much more painful :) no shade on go, of course having a binary built for your system is the most painless.

Re: 2026: The Year of Java in the Terminal?

#105

Why? It's not well suited to it - fundamentally the language semantics lead to very large distributions, slow startup and expecting a runtime on the machine. Okay, I hear this can be solved by Graal, but that's a whole piece of its own complexity that you'd never have to worry about with a tool written in something like Go. Python has many similar properties, but at least there I can understand that Python is a 'pret…

Regarding slow startups, I am not sure this applies to any use cases I can think of where it would not also be a concern in python, etc. JVM startup times have never meaningfully impacted my workflow in the last 15 years.

The why is quite simple, in my opinion. I see java devs reaching for other accepted tools for such things and opening a whole can of worms by introducing a new language that is only "required" by convention. I would love a rich java ecosystem of TUI/CLI libraries to reuse all of my existing business logic and company libraries. The lack of extremely streamlined wrappers is the only barrier. In my work environment, this would be a great addition.

Re: 2026: The Year of Java in the Terminal?

#106
post #74
post #18

Java 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 int…

Java SHOULD never become a player in anything more until Oracle stops being such a threat. Oracle just wants to be a parasite on companies that actually build.

I like that Microsoft has a distribution of OpenJDK. Easy to trust if I'm on a windows system anyway. What's the risk?

https://www.microsoft.com/openjdk

Re: 2026: The Year of Java in the Terminal?

#107

It just so happens that I’ve built one already: TUI4J (Terminal User Interface for Java). https://github.com/WilliamAGH/tui4j It combines a port of BubbleTea from Go, and Textual and other inspired rewrites of other functionality. It’s a fork of someone’s earlier work that I sought to expand/stabilize. I built a beautifully simple LLM chat interface with full dialog windows, animations, and full support for keyboard…

I had no idea what brief was until I read the env var api key docs in the subdirectory. I think you should not lead with "it's a tui4j app!" and "it's terminal chat!". It's a terminal OpenAI ChatGPT interface. Screenshot wouldn't hurt either, given it's an advertisement for the presentation library.

Re: 2026: The Year of Java in the Terminal?

#108
You can do this in Java 21, create this small Java file and run it immediately:

    class HelloWorld {
        public static void main(String[] args) {
            System.out.println("Hello, World!"); 
        }
    }
    
    java HelloWorld.java
Include the .java extension, you're running the file directly.

time java HelloWorld.java

    Hello, World!

    real    0m0.278s
    user    0m0.613s
    sys     0m0.066s

Re: 2026: The Year of Java in the Terminal?

#109
I'm sorry, but this is a big load of crap and that includes some of the comments in here. Java enthusiasts are the absolute world champions of sugarcoating the shortcomings of Java and the JVM in general.

This is what writing a CLI application in Go looks like: you download Go and immediately have all the tools needed to manage dependencies, write applications, and compile them into lightweight, distributable binaries with a simple command.

Now, let’s consider how this process looks in Java. First, you need to download A(!) JDK – and there are multiple ones. Many newcomers struggle with the variety of JDKs, but let's move past that. The JDK alone doesn’t handle dependencies; it’s highly likely you’ll end up using either Maven or Gradle, both of which are complex and tiresome, requiring you to deal with either XML (Maven) or Groovy/Kotlin. What seems to be missed is the potential of tools like JBang, which should ideally come out of the box. The Scala people addressed this effectively with scala-cli which is now the default Scala runner. Anyway, you’re still far from finished. You've just figured out how to write applications; now you need to figure out how to distribute them. This involves understanding jpackage – if you want an application smaller than 100MB, you’ll likely need to use jlink beforehand. And, heaven forbid, your application uses Java 9+ modules, as then you'll be wrestling with the complexities of modularity itself. If you’ve managed to navigate all of this, you’ll end up with an application that includes a bundled JRE. A compressed, modularized “hello world” application can easily size at least 30MB and take several hundred milliseconds to start.

Then there's Graal Native, which allows you to compile your applications ahead of time into natively executable binaries. However, compiling Java applications ahead of time is complicated by runtime class initialization, reflection etc. which is why the Graal compiler needs significant configuration beforehand. There are tracing agents to help you compile such configurations, but even with them, it’s incredibly tiresome and not always reliable. Furthermore, the produced binaries tend to be large and don't play well with upx.

I think the JDK developers could learn from Scala CLI, which is now the default Scala runner. I'm convinced it would really help Java if it came with something like that out of the box.

Re: 2026: The Year of Java in the Terminal?

#110
post #25

There are approximately no use cases that would get me to run a CLI written in Java on my machine, especially if it required having a JVM installed. There's just no reason for it. The rounding error there is Pkl, which is at least built using Graal Native Image, but (IMO) would _still_ have better adoption if it was written in something else. That said, if the Java community wanted to port reasonable tooling to their…

Assuming JVM installation is not required (to which I agree, it shouldn't be), why would you care which language a CLI tool is written in? I mean, do you even know whether a given binary is implemented in Go, Rust, etc.? I don't see how it makes any meaningful difference from a user perspective. > Pkl, which is at least built using Graal Native Image, but (IMO) would _still_ have better adoption if it was written in…

It makes a difference in size, in how arguments tend to be handled, and so forth.

As for why Pkl was in Java: it was originally built to configure apps written in Java, and heavily uses Truffle. Pkl is a name chosen for open sourcing, it had a different name internally to Apple before that which made the choices a little more obvious.

Post reply on HN