9 ms·

2026: The Year of Java in the Terminal?

112 points by based2 9mo ago

based2 9mo ago
from https://old.reddit.com/r/java/comments/1pzfmka/2026_the_year_of_java_in_the_terminal/ https://old.reddit.com/r/java/comments/1pzfmka/2026_the_year... https://www.jbang.dev/ https://www.jbang.dev/
f2hex 9mo ago
Java is legacy... when you started working with Python, Golang, Rust, Typescript, Swift... still need Java??
- newsoftheday 9mo ago
  Legacy doesn't seem to mean what you are implying. I suggest typing the following prompt into any AI and debating it with the AI: "define legacy in terms of programming languages".
whalesalad 9mo ago
I would use this instead, https://babashka.org/ https://babashka.org/
- rgreeko42 9mo ago
  came here to say the same
- Eduard 9mo ago
  babashka is for clojure
  - whalesalad 9mo ago
    clojure is java. you have full access to the entire ecosystem, with none of the headaches.
- deleted 9mo ago
  [deleted]
reactordev 9mo ago
The 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.
- krzyk 9mo ago
  Go and "simpler"? Really? C is simpler, Python is simpler, but Go?
  - jen20 9mo ago
    Yes - Go is both a simpler language than Java which does not lend itself to (nor does the ecosystem tolerate) the kind of architectural malpractice that enterprise Java typically becomes.
  - reactordev 9mo ago
    Indeed https://leapcell.io/blog/the-origins-and-design-philosophy-of-go-language https://leapcell.io/blog/the-origins-and-design-philosophy-o... Go was originally designed to make life easier for googlers and make software engineering easy. In 2025, I can attest to the fact that Go is simple. Go is easy. Whether you can accomplish what you want in Go is another story. However, Go has a very basic structure and easy flow. Complexity comes from not understanding the go philosophy.
  - nu11ptr 9mo ago
    Go is one of the simplest languages there is. Not always easy to create something at scale IMO, but certainly simple.
aziis98 9mo ago
I didn't know about JBang, it looks awesome. Does it work somewhat like uv?
ecshafer 9mo ago
Java 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 compiled Java programs has been a life saver. Running java -jar main.java -foo -bar is very annoying and not friendly. It needs to be packaged so you can just run tool -foo -bar
- xg15 9mo ago
  +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".
nickstinemates 9mo ago
Very clearly written by AI. Java in the terminal sounds awful. Programming Java is awful. No thank you.
- ebiester 9mo ago
  When did you last program Java? It’s changed a lot from the Java 8 days. I am not in the ecosystem anymore but it did a lot of things right.
  - jen20 9mo ago
    I concur with Nick, and the last time I programmed Java professionally was late 2024, with all of the latest and greatest frameworks (obviously not my choice) and tooling (which, to be fair to the Java ecosystem, is second to none). The experience after having spent over a decade primarily doing Go, Rust and Erlang (with a smattering of TypeScript, C#, Python, Swift, C, C++ etc) was the final push over the line to leave that employer.
- gunnarmorling 9mo ago
  Can you back up your claim the post is written by AI?
  - jen20 9mo ago
    I'm not sure I'd go so far as to claim it was definitely written by AI (after all, LLMs tend to write the way they do because it reflects their training material), but it does have a large number of suspicious constructions that suggest it could have been: - "Look, I’m going to say something that might sound crazy...." - But here’s the thing: there’s nothing stopping us... - Emdashes. I don't believe that alone they are a tell for AI any more than they are a tell for the cultured, but in combination with other things, maybe. - The question/answer style. - The "It's not X, It's Y" construction. This is all in the first sections.
    - oncallthrow 9mo ago
bsan3 9mo ago
Agree, Java also had straight single file execution forever now. Java foo.java. I use it instead of scripts all the time. Solid language with a lot of flexibility, Oracle has done a good job in last few years. Newer Java frameworks are fairly easy and light to use. We have natively image Lambda functions in production. Work well.
- dionian 9mo ago
  how does this handle classpath
- javcasas 9mo ago
  Imagine having to know the programming language used to write a program to run it. $ python foobar Nope. $ gcc foobar Nope. $ g++ foobar Aw,come on. $ go foobar Damnit. $ rust foobar $ c# foobar WTF did they use for this program??!! $ node foobar This is such a waste of time. $ java foobar Bullshit! $ ocaml foobar Come on, there arent't that many more programming languages! $ tcl foobar Finally!
  - maxandersen 9mo ago
    thats why you use jreleaser and publish it so you just run it as `foobar` Lets please not mix up good dev flows with end user flows...this is not unique problem for java.
larusso 9mo ago
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.
- vips7L 9mo ago
  Using modules and jlink your Java image would be much smaller than 200mb. Full desktop apps with ui’s can get down to 30mb. I’m confused by your disregard of C# AOT. It produces binaries as small as go or rust. 1.1 MB for hello world on linux.
  - larusso 9mo ago
    But it takes ages to compile. Or at least that was my experience with .NET9 a few years back.
    - newsoftheday 9mo ago
      Are you really a developer, because it sounds like you're conflating or confusing language technologies?
    - vips7L 9mo ago
      On WSL/Fedora 43, building hello world: > time dotnet publish Restore complete (0.4s) dn-hw net10.0 linux-x64 succeeded (2.4s) → bin/Release/net10.0/linux-x64/publish/ Build succeeded in 3.1s real 0m3.571s user 0m2.784s sys 0m0.673s > time go build main.go real 0m3.309s user 0m8.864s sys 0m1.741s Obviously I don't know how that translates to a non-trivial application.
sneakinsnake 9mo ago
Go?
thefaux 9mo ago
> Try a GraalVM native image. Milliseconds. Gone. Try building a GraalVM native image. Minutes gone.
- vips7L 9mo ago
  More gigabytes of ram than your machine has will be gone too.
  - Alifatisk 9mo ago
    Luckily, that's only during aot compilation and not runtime.
    - twoodfin 9mo ago
      Right but the inspiration for this article is using Java as a terminal vibe coding language, so the aot step would be part of the critical path. I’m not surprised this was not obvious to the LLM that “cleaned up my notes” for the “author”.
- maxandersen 9mo ago
  I agree the build might take a bit extra but its for sure not much for smaller clis. Making jbang native added 1-2 minutes and its all done in github action runners so in practice I don't see this as a problem as it does not affect the end user.
FriendlyMike 9mo ago
I'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
- megadopechos 9mo ago
  > 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.
- Scubabear68 9mo ago
  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).
- mbreese 9mo ago
  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.
- 9mo ago
laughingcurve 9mo ago
The 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
- newsoftheday 9mo ago
  Someone else on the page commented about Oracle. Why are there still people hung up on Oracle or Ellison when if anything, they've helped Java to thrive more. The real threat has been and continues to be ... Google. They pulled a Microsoft move (that they got busted for) and Google got away with it. Google killed Eclipse as the IDE for Android development and threw that business over to their Russian buddies at JetBrains. Google is the threat to Java, not Oracle.
- waffletower 9mo ago
  I'm a progressive -- just as I am not dumping my climate friendlier Tesla at a loss because Musk is a Nazi buffoon, there is no way I am walking away from my GraalVM compiled babashka binary because another billionaire turd kicked Stephen Colbert off the tonight show. I can mourn and label both as petulant and stupid, without having to bleed my back like Saint Thomas More.
vips7L 9mo ago
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 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.
- chamomeal 9mo ago
  Yeah it’s funny how “Java runs everywhere” was a huge selling point of the JVM. But now it’s not even included in macOS by default, so if you want somebody to use you Java/clojure CLI they have to install Java. And that will raise eyebrows and make people think “what is this, 2010??”
  - voidfunc 9mo ago
    jpackage It does all of this work for you and its a standard tool that dumps out a platform specific application bundle. The only people living in 2010 are the ones that choose to live there with incredibly outdated takes on things they dont understand.
    - vips7L 9mo ago
      Has jpackage been updated to create things that are not installers and don't extract themselves into several files?
      - voidfunc 9mo ago
        You're asking about a fundamentally different thing. An app bundle (.app, .rpm, .deb, .msi/.exe etc.) are things jpackage can build for you and are a single shippable artifact for a user with a JRE included so they don't need to do that. It's designed to make it easy to ship Java applications around. If you want a fully statically linked binary you're diving into graalvm and native-image: https://www.graalvm.org/latest/reference-manual/native-image/ https://www.graalvm.org/latest/reference-manual/native-image.... This will give you what you want which is basically something you can wget and chmod +x.
waffletower 9mo ago
Babashka has been available and has had a growing following since 2019. I have many babashka shebang deployed scripts with fast startup. While I would never desire to use Java syntax, AOT capable JVM based Clojure libraries are available and can be loaded dynamically. Built via graal. https://babashka.org https://babashka.org
- waffletower 9mo ago
  babashka comes with some excellent namespaces. Highlights include babashka.fs -- a functional and effective wrapper around Java file system classes, and babashka.process -- useful functions for interacting with shell processes, i/o and pipelines. I find babashka packaging to be minimal and much more convenient than python for scripting. No massive virtual environments, just a smaller than 70mb binary needs to be available on my machine. Borkdude FTW.
  - maxandersen 9mo ago
    Yes - this is what we need more off - just not only in clojure space. I done https://github.com/jbangdev/jbang-jash https://github.com/jbangdev/jbang-jash for shell processes and smallrye process io also done a lot for nice shell apis. Files access could be another. jbang provides the similar binary - for now bash+jvm based but all simple installable. I have native jbang binaries which are even less than 70 mb :) Definitely going to check out babashka more for inspiration.
WD-42 9mo ago
Looking forward to implementing a AbstractCommandlineParserFactoryBeanServicePatternFactory
- gred 9mo ago
  > AbstractCommandlineParserFactoryBeanServicePatternFactory ...Locator
- maxandersen 9mo ago
  it shows you definitely use a certain niche of Java but I hear you on the funny part. When I started showing that its just fine to name a class, `myapp` and run it with jbang myapp.java people got all weirded out. No technical constraints in java; just bad old habits limiting peoples mindset ;)
jen20 9mo ago
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 platform, I'm sure Claude could do a reasonable job of getting a decent chunk of BubbleTea and friends bootstrapped.
- gunnarmorling 9mo ago
  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 something else. Why do you think is this?
  - jen20 9mo ago
    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.
- asa400 9mo ago
  > That said, if the Java community wanted to port reasonable tooling to their platform, I'm sure Claude could do a reasonable job of getting a decent chunk of BubbleTea and friends bootstrapped. There's a poster upthread who seems to have done what you're describing: https://github.com/WilliamAGH/tui4j https://github.com/WilliamAGH/tui4j
elzbardico 9mo ago
Well, the year is 2003 and I am on a hot dungeon with bad Air Conditioning, figuring out the correct spells for a black magic ant build. A few years later I am writing tons of XML, first for vanilla J2EE, then for spring. We complained, we wondered, nobody cared until one day we decided "fuck that shit, I don't care if ruby is slow as molasses, I just want the pain to go away!" Forgive me if in 2026 I get triggered at the mere mention of the phrase "java build". Lots of us had long relationships with Java, relationships marked by toxicity and abuse. We moved on. Now Java says it is changed, it has matured. Well, it could be true, probably it is even true, but on the other hand, now your toxic ex found out his father, and his name is Larry Ellison.
- maxandersen 9mo ago
  I guess I should never use Go because I was stuck not having a working debugger, complain about Python because it is single threaded, or javascript because its a typeless mess, or C# for only running on Windows? I'm happy to say I think all have their upsides and downsides and all of them evolve and should all try not to be stuck in old perceptions. And yes Java is held back by those perceptions and I'm saying lets not get bogged down by perceptions like yours from trying to evolve and improve.
TacticalCoder 9mo ago
I've been writing Java utils for the terminal since forever. Mostly because I was extremely familiar with Java. It's never been really slow unless you were loading shitload of classes, like apps that package the entire kitchen sink do or as Clojure does for example. For Clojure now there's Babashka: super quick. And GraalVM compiled Java is more than speedy. Back in, say, 2005, two decades ago, on computers from back then, sure, the java startup time from the CLI were noticeable. But on today's computers? Nowadays when it comes to terminal apps I wrote both Clojure (Babashka), Bash and Java (recently I needed something from a .jar and had no convenient Clojure wrapper and didn't want to bother, so I just wrote my CLI app in Java). Maybe, maybe, maybe that I do feel the startup time when I run my CLI Java app on Raspberry Pis. Raspberry Pi 2 and 3s that is (for I don't have any newer). Startup times aren't an issue. But there may be other reasons to prefer other languages to write CLI apps.
oncallthrow 9mo ago
No, Java (or frankly anything JVM-based) on the terminal is a terrible experience.
gunnarmorling 9mo ago
As a practical example for a Java-based CLI tool in the wild, here's kcctl, a command line client for Kafka Connect: https://github.com/kcctl/kcctl/ https://github.com/kcctl/kcctl/. It's a native binary (via GraalVM), starting up in a few ms, so that it actually be invoked during tab completions and do a round-trip to the Kafka Connect REST API without any noticeable delay whatsoever. Installation is via brew, so same experience as for all the other CLI tools you're using. The binary size is on the higher end (52 MB), but I don't think this makes any relevant difference for practical purposes. Build times with GraalVM are still not ideal (though getting better). Cross compilation is another sore point, I'm managing it via platform-specific GitHub Action runners. From a user perspective, non of this matters, I'd bet most users don't know that kcctl is written in Java.
wcallahan 9mo ago
It just so happens that I’ve built one already: TUI4J (Terminal User Interface for Java). https://github.com/WilliamAGH/tui4j 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 and mouse interactivity parity, showing what this Java library is capable of. Example chat app: https://github.com/WilliamAGH/brief https://github.com/WilliamAGH/brief Would love to see others build similar things with it!
- dundarious 9mo ago
  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.
  - wcallahan 9mo ago
    Great ideas for both :) I wasn’t expecting the main topic of what I’ve been building to appear on the cover of hacker news today, so I was caught a bit unprepared, but they were definitely on the todo list next!
- maxandersen 9mo ago
  cool - you've hidden that well as I spent a lot of time searching for these. Will definitely check it out. ...where is the jar for brief? :)
  - maxandersen 9mo ago
    ah - tui4j is continuation of latte. Cool - now I grok why it looked similar. cool!
    - wcallahan 9mo ago
aoli-al 9mo ago
My biggest complaint about Java development is the state of LSP/DAP support. I’ve tried writing Java in VS Code, and the support is still very incomplete. There are two features I want the most: (1) automatically downloading source code for dependencies, and (2) pausing all threads when a breakpoint is hit (https://github.com/microsoft/vscode-java-debug/issues/722 https://github.com/microsoft/vscode-java-debug/issues/722 ). I can’t find any editor or IDE that comes close to IntelliJ. If we want Java in the terminal, we may also need to think how to write Java in the terminal or are they orthogonal?
- maxandersen 9mo ago
  hmm - automatic download of source code just works for me in vscode...? "java.maven.downloadSources": true in config if you don't just use maven's automatic download for it. pause all threads does look like a valid omission. Feels like something someone should go contribute - any takers? on your question - I do actually miss having a good an easy java in terminal editing experience. I use a nvim starter pack to do it BUT here there is no good jbang enabled LSP to make it truly smooth ...also on my 2026 wish list :)
timcobb 9mo ago
2026 is going to be the year of learning languages as you review LLM generated code
RickJWagner 9mo ago
Languages lose users when the tooling becomes too heavy. You have to learn ( and maintain knowledge of ) build tooling, unit test frameworks, tools for front end / back end development, distribution and packaging systems, directory structures to accommodate all those, etc. ad nauseum. Then something new and shiny comes out, with much smaller tooling. The lure of easy software construction seduces the user. It never ends.
tgpc 9mo ago
use rust or go, please single binary, no complex deps, ftw
Alifatisk 9mo ago
I wish the article dug deeper into how the workflow would look like in the practical sense when using jBang and jReleaser.
- maxandersen 9mo ago
  Thats part of what I want to do more of in 2026 and I hoping others will help as otherwise I'll just be sitting in my own quiet echo chamber :)
languagehacker 9mo ago
Will 2026 be the year hammers get a little phillips head on the back in case you run into one of those weird ribbed nails?
binarymax 9mo ago
The question mark at the end is an easy out for us to claim Betteridge’s law.
- Eduard 9mo ago
  "Does binarymax understand the concept of yes-no questions?"
- maxandersen 9mo ago
  Yeah, well - I didn't make a factual claim and then questioned it. I asked who is with me? - and no nor yes is not a meaningful answer to that :)
mellosouls 9mo ago
Strangely, not a mention of groovy which I seem to remember was somewhat motivated by use cases such as this?
thomashabets2 9mo ago
I'm not saying we should phase Java out. But it's pretty clear to me that Java was a bad experiment in almost every aspect, and we should at least not add new use cases for it. So no. No, please god no, no Java in the terminal. More ranting here: https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experiments.html https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim...
- ktpsns 9mo ago
  And yet Java is more then Java. There are lots of more modern languages on the JVM. The ecosystem is huge and still has lots of inertia.
  - thomashabets2 9mo ago
    Yeah. Some of my critique applies to the language, some on the JVM and thus cross language. Kotlin sure is less awful, for example. But the JVM, as I describe, was always a failed experiment.
wolfi1 9mo ago
how about jshell? it comes with every java distribution
- tpoacher 9mo ago
  yes I thought this was going to be about jshell too. jshell is amazing, I don't think enough people know about it!
- wewtyflakes 9mo ago
  Shameless plug for jshelled (jshell for gradle projects) https://github.com/gravitation1/jshelled https://github.com/gravitation1/jshelled
bfung 9mo ago
Article meta comment: show me, don’t tell me. No show —> not easy enough —> too lazy to look it up, already got python/go/ruby quick cli methods. LLM generated even easier.
martylamb 9mo ago
I spent a long time caring about JVM startup time and CLI suitability (and wrote nailgun [0] over 20 years ago and jsap [1] shortly after specifically because of it), so it's pretty wild to see how far things have come. Modern JVM startup speed and GraalVM native-image have eliminated most of the old excuses. jlink+jpackage help a lot with distribution, and JBang takes it to another level. I've used JBang before but still learned some new tricks from this post. Honestly, it feels like what JNLP/WebStart should have evolved into. I'm not convinced that requiring users to already have JBang installed is the best adoption strategy. But a native package that pulls in JBang if needed and drops a shim launcher/desktop shortcut seems like a natural approach and maybe a fun project. On the TUI side, java could really use something as approachable and pretty as go's Charmbracelet [2]. Once developers regularly see compelling java TUIs in the wild, it'll change their perception. The tooling is here, or at least really close. At this point, it's mostly outdated opinions holding java back in the terminal. [0] https://martiansoftware.com/nailgun https://martiansoftware.com/nailgun [1] https://martiansoftware.com/jsap/ https://martiansoftware.com/jsap/ [2] https://github.com/charmbracelet https://github.com/charmbracelet
- slowmovintarget 9mo ago
  Strokes chin inquisitively in Babashka... hmmm... Edit: Heh... https://rattlin.blog/bbgum.html https://rattlin.blog/bbgum.html
  - martylamb 9mo ago
    That's a cool approach!
ninth_ant 9mo ago
I get the argument from this article that it’s possible. But I don’t get the argument that this is somehow desirable. Just because it’s possible to smash a square peg into a round hole doesn’t make it a good idea.
- ivan_gammel 9mo ago
  The argument is probably that it’s no longer square.
- maxandersen 9mo ago
  I'm definitely not going try to force it upon those who don't like java - but I'm saying that the Java peg is way more round than most believe so don't just start using another slightly round peg like python, go, javascript etc. because others said its required :)
nathell 9mo ago
Java in the terminal works exquisitely well already, and it’s called Babashka. Clojure rocks, Bash reaches, and Java provides a rock-solid foundation.
- newsoftheday 9mo ago
  It sounds Russian, no thanks.
CamouflagedKiwi 9mo ago
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 'pretty' language to write things in. Java has never been something that I have ever wanted to choose, and far, far less so when there's a big hill to climb like this. I guess I fundamentally disagree with all the statements in the article like "This needs to change". I don't think it does. I would much rather than people wrote CLIs in Go or Rust than Java, 100% of the time the latter has been more painful for me to consume.
- jazzyjackson 9mo ago
  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.
- unlikelytomato 9mo ago
  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.
  - CamouflagedKiwi 9mo ago
    Right, as I said I also think Python has similar issues with startup time. I've used a limited amount of Java CLIs, the most obvious ones are things like Gradle which never felt snappy to use - it is annoying when even doing basic things takes 2+ seconds. I guess not the end of the world, but that seems suboptimal to me compared to a system that feels fast to use and hence well engineered.
nailer 9mo ago
But latency. No Java app I have used in 25ish years has ever started in a reasonable amount of time.
- thangalin 9mo ago
  > 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.
  - nailer 9mo ago
    It’s not a generalisation. I am a specific individual relating my own experiences. I have no idea what your app is and have had zero reason to use it.
- gunnarmorling 9mo ago
  It's a non-issue with GraalVM native binaries. See https://news.ycombinator.com/item?id=46445989 https://news.ycombinator.com/item?id=46445989 for an example: this CLI tools starts in ms, fast enough you can launch it during tab completions and have it invoke a REST API without any noticeable delay whatsoever. But also when running on the JVM, things have improved dramatically over the last few years, e.g. due to things such as AOT class loading and linking. For instance, a single node Kafka broker starts in ~300 ms.
  - cb321 9mo ago
    Time comparisons are (or should be) relative. https://news.ycombinator.com/item?id=46447490 https://news.ycombinator.com/item?id=46447490 graalvm is literally 500x more overhead than a statically linked dash script. Maybe not an issue for terminal UIs, but the article mentions both TUIs and CLI tools. A lot of people use CLI tools with a shell. As soon as you do `for file in *.c; do tool "$file"; done` (as a simple example), pure overhead on the order of even 10s of ms becomes noticeable. This is not theoretical. I recently had this trouble with python3, but I didn't want to rewrite all my f-strings into python2. So, it does arise in practice. (At least in the practice of some.)
idkana 9mo ago
[dead]
newsoftheday 9mo ago
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
- oftenwrong 9mo ago
  You can do better now: #!/usr/bin/env java --source 25 void main() { IO.println("Hello, World!"); } https://openjdk.org/jeps/330 https://openjdk.org/jeps/330 https://openjdk.org/jeps/458 https://openjdk.org/jeps/458 https://openjdk.org/jeps/512 https://openjdk.org/jeps/512 I often combine these approaches with https://get-coursier.io/ https://get-coursier.io/ when I need to fetch third-party dependencies.
pregnenolone 9mo ago
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.
- deleted 9mo ago
  [deleted]
- maxandersen 9mo ago
  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. Love you too. 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. Check - agreed. Now, let’s consider how this process looks in Java....<rant> It feels like you missed the last 5 years of improvements..so let me show you how this works in java when using jbang: You download JBang, and immediately have all the tools needed to manage dependencies, write applications, and run other Java applications with a simple command. Since you probably don't believe me I'll show you some of it here: `jbang init -t cli hello.java` - you get a hello.java that declare picocli dependencies and you can run it as `./hello.java`, you even do `jbang app install hello.java` and just use `hello`. You can do this with your own scripts, preexisting jars or existing Maven artifacts. - yes it will also have downloaded right JDK for you; you can easily swith to other versions, either `jbang --java 25 hello.java` or even `jbang --java 8 hello.java` if you really wanna go back in time :) The java version can be baked into your script or jar so it is NOT a requirement for your end user to be aware. `jbang edit hello.java` will offer to install vscodium based IDE that gives you an IDE environment to write java in. `jbang export fatjar hello.java` gives you a runnable fat.jar `jbang export maven|gradle hello.java` gives it a full blown maven/gradle if you are forced to be Enterprise Compliant :) You can even run and distribute these sources by just commiting to a github repo and just do `jbang <repourl>` or use jbang catalogs etc. Lots of opportunities. Reading this and reddit thread I see that the final publish of jars/executables is still too tedious I'm going to try solve that challenge as we have all the pieces (IMO) with jbang/jreleaser and modern JDKs. 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. don't play well with upx - how so? yes there is the usual upx overhead but "just works" when I tried using it? about graalvm native - definitely not going to say its perfect nor easy; but Quarkus definitely have a whole ecosystems of java libraries and framework setup that just works when using native builds. That said - I think we dont need to go to full native for lots of usecases. 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. Yeah, I couldn't wait for JDK developers to do it so I built jbang to make that available today.
cb321 9mo ago
Haven't checked graalvm in a long time. So, I got graalvm-jdk-25.0.1+8.1 for x86_64. It's a lot faster than Julia, and maybe 43ms is not slow in "human terms", but it's still pretty slow compared to some other competition. This was for a helloworld.jar [1]. On my laptop (i7-1370P, p-cores) using tim[2]: $ tim "awk '{}'</n" 'tcc -run /tmp/true.c' 'perl</n' 'py2</n' 'py3</n' 'java -jar helloworld.jar>/n' 97.5 +- 1.5 μs (AlreadySubtracted)static dash Overhead 94.9 +- 3.2 μs awk '{}'</n 376.7 +- 4.6 μs tcc -run /tmp/true.c 525.3 +- 2.7 μs perl</n 3627.7 +- 6.0 μs py2</n 6803 +- 11 μs py3</n 42809 +- 71 μs java -jar helloworld.jar>/n Also, probably there is some way to tune this, but it used over 128 MiB of RSS. [1]: https://github.com/jarirajari/helloworld https://github.com/jarirajari/helloworld [2]: https://github.com/c-blake/bu/blob/main/doc/tim.md https://github.com/c-blake/bu/blob/main/doc/tim.md
- NovaX 9mo ago
  That is just a normal JVM with optional Graal components if enabled, but not being used. The default memory allocation is based on a percentage of available memory and uncommitted (meaning its available for other programs). When people mention Graal they mean an AOT compiled executable that can be run without a JVM installed. Sometimes they may refer to Graal JIT as a replacement for C1/C2 available also in VM mode. You are using a plain HotSpot VM in server mode, as the optimized client mode was removed when desktop use-cases were deprioritized (e.g. JWS discontinued).
  - cb321 9mo ago
    You are correct and I apologize for the misimpression. `native-image -jar helloworld.jar helloworld` did take a whopping 17 seconds to compile, what might be the smallest possible project. That does makes me worry for iterations trying to get better perf in a context where startup overhead matters, BUT the executable it produced did run much faster - only about 1.8x slower than `tcc -run`: 97.0 +- 1.7 μs (AlreadySubtracted)Overhead 98.2 +- 2.8 μs awk '{}'</n 376.4 +- 4.4 μs tcc -run /tmp/true.c 527.9 +- 4.0 μs perl</n 686.5 +- 3.9 μs ./helloworld>/n Perl has 2 more shared libraries for ld.so to link, but is somehow faster. So, there may still be some room for improvement, but anyway, thank you for the correction. (Also, I included 4 of the faster comparative programs to show additionally that the error bars are vaguely credible. In truth, on time shared OSes, the distributions have heavier tails than Gaussian and so a single +- is inadequate.) -- EDIT: So, the ld.so/dynamic linking overhead was bothering me. I had to get a musl + zlib build environment going, but I did after a few minutes and then found this result with a fully statically linked binary executable: 398.2 +- 4.2 μs ./helloworld-sta>/n (I should have noted earlier that /n -> /dev/null is just a convenience symlink I put on all my systems. Also, this is all on Linux 6.18.2 and the same CPU as before.) Also, only around 4.2 MiB of RSS compared to ~1.8 MiB for dash & awk. So, 2.4x the space and only ~4X the time of static awk & dash. That might sound like criticism, but those are usually the efficiency champs. The binary size is kind of hefty (~2x like the RAM use): $ size *sta text data bss dec hex filename 2856644 3486552 3184 6346380 60d68c helloworld-sta So, I guess, in 2026, Java start-up overhead is pretty acceptable. I hope that these "real numbers" can maybe add some precision to the discussion. Someone saying "mere milliseconds" just does not mean as much to me as 400 +- 4 microseconds, and perhaps there are others like me.
tylerchilds 9mo ago
Going to be honest Absolutely shocked Java wasn’t in the terminal I know I don’t use it, but wow. Honestly, super impressed that that they’ve got the traction they do without it but, I think the takeaway is that Java developers like having everything in the IDE— so I’d imagine agentic in the ide will yield higher returns than switching modalities
- maxandersen 9mo ago
  There is already a lot of Java in agentic systems and IDE integrations — but that alone won’t break the stereotype. The real blocker isn’t capability, it’s perception: many people stop before even trying Java in the terminal. All while Python/JS are seeing a surge in terminal tooling, despite similar (or worse) startup cost, dependency sprawl, and multi-GB installs — and the reaction there is often “this is fine, let’s ship and use.” Until Java is visibly normal in the terminal, agentic features in IDEs won’t change that mental model.
weinzierl 9mo ago
It is not only the language but also the mindset and culture. When in Java System.exit() and even System.println() are treated as smells and I have to actively push to get exceptions from the company wide style I'll just write Rust and be done.
- ivan_gammel 9mo ago
  Company wide styles that restrict things generally rather than putting them in context are bad smell itself.
- maxandersen 9mo ago
  Thats my whole point in my blog - we need to change the mindset. Other ecosystems just have much less "enterprise rules" applied to them - break free :)
0xCAP 9mo ago
Let's hope not.
aap_ 9mo ago
Java feels like the COBOL of our times, and the JVM like the IBM 360 architecture.
maxandersen 9mo ago
Author of blog here - this was posted just as I started eating my New Year Dinner - Happy New Year :)

112 points by based2 9mo ago

from https://old.reddit.com/r/java/comments/1pzfmka/2026_the_year_of_java_in_the_terminal/ https://old.reddit.com/r/java/comments/1pzfmka/2026_the_year... https://www.jbang.dev/ https://www.jbang.dev/

f2hex 9mo ago

Java is legacy... when you started working with Python, Golang, Rust, Typescript, Swift... still need Java??

newsoftheday 9mo ago
Legacy doesn't seem to mean what you are implying. I suggest typing the following prompt into any AI and debating it with the AI: "define legacy in terms of programming languages".

whalesalad 9mo ago

I would use this instead, https://babashka.org/ https://babashka.org/

rgreeko42 9mo ago
came here to say the same
Eduard 9mo ago
babashka is for clojure
- whalesalad 9mo ago
  clojure is java. you have full access to the entire ecosystem, with none of the headaches.
deleted 9mo ago
[deleted]

reactordev 9mo ago

The 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.

krzyk 9mo ago
Go and "simpler"? Really? C is simpler, Python is simpler, but Go?
- jen20 9mo ago
  Yes - Go is both a simpler language than Java which does not lend itself to (nor does the ecosystem tolerate) the kind of architectural malpractice that enterprise Java typically becomes.
- reactordev 9mo ago
  Indeed https://leapcell.io/blog/the-origins-and-design-philosophy-of-go-language https://leapcell.io/blog/the-origins-and-design-philosophy-o... Go was originally designed to make life easier for googlers and make software engineering easy. In 2025, I can attest to the fact that Go is simple. Go is easy. Whether you can accomplish what you want in Go is another story. However, Go has a very basic structure and easy flow. Complexity comes from not understanding the go philosophy.
- nu11ptr 9mo ago
  Go is one of the simplest languages there is. Not always easy to create something at scale IMO, but certainly simple.

aziis98 9mo ago

I didn't know about JBang, it looks awesome. Does it work somewhat like uv?

ecshafer 9mo ago

Java 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 compiled Java programs has been a life saver. Running java -jar main.java -foo -bar is very annoying and not friendly. It needs to be packaged so you can just run tool -foo -bar

xg15 9mo ago
+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".

nickstinemates 9mo ago

Very clearly written by AI. Java in the terminal sounds awful. Programming Java is awful. No thank you.

ebiester 9mo ago
When did you last program Java? It’s changed a lot from the Java 8 days. I am not in the ecosystem anymore but it did a lot of things right.
- jen20 9mo ago
  I concur with Nick, and the last time I programmed Java professionally was late 2024, with all of the latest and greatest frameworks (obviously not my choice) and tooling (which, to be fair to the Java ecosystem, is second to none). The experience after having spent over a decade primarily doing Go, Rust and Erlang (with a smattering of TypeScript, C#, Python, Swift, C, C++ etc) was the final push over the line to leave that employer.
gunnarmorling 9mo ago
Can you back up your claim the post is written by AI?
- jen20 9mo ago
  I'm not sure I'd go so far as to claim it was definitely written by AI (after all, LLMs tend to write the way they do because it reflects their training material), but it does have a large number of suspicious constructions that suggest it could have been: - "Look, I’m going to say something that might sound crazy...." - But here’s the thing: there’s nothing stopping us... - Emdashes. I don't believe that alone they are a tell for AI any more than they are a tell for the cultured, but in combination with other things, maybe. - The question/answer style. - The "It's not X, It's Y" construction. This is all in the first sections.
  - oncallthrow 9mo ago

bsan3 9mo ago

Agree, Java also had straight single file execution forever now. Java foo.java. I use it instead of scripts all the time. Solid language with a lot of flexibility, Oracle has done a good job in last few years. Newer Java frameworks are fairly easy and light to use. We have natively image Lambda functions in production. Work well.

dionian 9mo ago
how does this handle classpath
javcasas 9mo ago
Imagine having to know the programming language used to write a program to run it. $ python foobar Nope. $ gcc foobar Nope. $ g++ foobar Aw,come on. $ go foobar Damnit. $ rust foobar $ c# foobar WTF did they use for this program??!! $ node foobar This is such a waste of time. $ java foobar Bullshit! $ ocaml foobar Come on, there arent't that many more programming languages! $ tcl foobar Finally!
- maxandersen 9mo ago
  thats why you use jreleaser and publish it so you just run it as `foobar` Lets please not mix up good dev flows with end user flows...this is not unique problem for java.

larusso 9mo ago

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.

vips7L 9mo ago
Using modules and jlink your Java image would be much smaller than 200mb. Full desktop apps with ui’s can get down to 30mb. I’m confused by your disregard of C# AOT. It produces binaries as small as go or rust. 1.1 MB for hello world on linux.
- larusso 9mo ago
  But it takes ages to compile. Or at least that was my experience with .NET9 a few years back.
  - newsoftheday 9mo ago
    Are you really a developer, because it sounds like you're conflating or confusing language technologies?
  - vips7L 9mo ago
    On WSL/Fedora 43, building hello world: > time dotnet publish Restore complete (0.4s) dn-hw net10.0 linux-x64 succeeded (2.4s) → bin/Release/net10.0/linux-x64/publish/ Build succeeded in 3.1s real 0m3.571s user 0m2.784s sys 0m0.673s > time go build main.go real 0m3.309s user 0m8.864s sys 0m1.741s Obviously I don't know how that translates to a non-trivial application.

sneakinsnake 9mo ago

Go?

thefaux 9mo ago

> Try a GraalVM native image. Milliseconds. Gone. Try building a GraalVM native image. Minutes gone.

vips7L 9mo ago
More gigabytes of ram than your machine has will be gone too.
- Alifatisk 9mo ago
  Luckily, that's only during aot compilation and not runtime.
  - twoodfin 9mo ago
    Right but the inspiration for this article is using Java as a terminal vibe coding language, so the aot step would be part of the critical path. I’m not surprised this was not obvious to the LLM that “cleaned up my notes” for the “author”.
maxandersen 9mo ago
I agree the build might take a bit extra but its for sure not much for smaller clis. Making jbang native added 1-2 minutes and its all done in github action runners so in practice I don't see this as a problem as it does not affect the end user.

FriendlyMike 9mo ago

I'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

megadopechos 9mo ago
> 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.
Scubabear68 9mo ago
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).
mbreese 9mo ago
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.
9mo ago

laughingcurve 9mo ago

The 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

newsoftheday 9mo ago
Someone else on the page commented about Oracle. Why are there still people hung up on Oracle or Ellison when if anything, they've helped Java to thrive more. The real threat has been and continues to be ... Google. They pulled a Microsoft move (that they got busted for) and Google got away with it. Google killed Eclipse as the IDE for Android development and threw that business over to their Russian buddies at JetBrains. Google is the threat to Java, not Oracle.
waffletower 9mo ago
I'm a progressive -- just as I am not dumping my climate friendlier Tesla at a loss because Musk is a Nazi buffoon, there is no way I am walking away from my GraalVM compiled babashka binary because another billionaire turd kicked Stephen Colbert off the tonight show. I can mourn and label both as petulant and stupid, without having to bleed my back like Saint Thomas More.

vips7L 9mo ago

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 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.

chamomeal 9mo ago
Yeah it’s funny how “Java runs everywhere” was a huge selling point of the JVM. But now it’s not even included in macOS by default, so if you want somebody to use you Java/clojure CLI they have to install Java. And that will raise eyebrows and make people think “what is this, 2010??”
- voidfunc 9mo ago
  jpackage It does all of this work for you and its a standard tool that dumps out a platform specific application bundle. The only people living in 2010 are the ones that choose to live there with incredibly outdated takes on things they dont understand.
  - vips7L 9mo ago
    Has jpackage been updated to create things that are not installers and don't extract themselves into several files?
    - voidfunc 9mo ago
      You're asking about a fundamentally different thing. An app bundle (.app, .rpm, .deb, .msi/.exe etc.) are things jpackage can build for you and are a single shippable artifact for a user with a JRE included so they don't need to do that. It's designed to make it easy to ship Java applications around. If you want a fully statically linked binary you're diving into graalvm and native-image: https://www.graalvm.org/latest/reference-manual/native-image/ https://www.graalvm.org/latest/reference-manual/native-image.... This will give you what you want which is basically something you can wget and chmod +x.

waffletower 9mo ago

Babashka has been available and has had a growing following since 2019. I have many babashka shebang deployed scripts with fast startup. While I would never desire to use Java syntax, AOT capable JVM based Clojure libraries are available and can be loaded dynamically. Built via graal. https://babashka.org https://babashka.org

waffletower 9mo ago
babashka comes with some excellent namespaces. Highlights include babashka.fs -- a functional and effective wrapper around Java file system classes, and babashka.process -- useful functions for interacting with shell processes, i/o and pipelines. I find babashka packaging to be minimal and much more convenient than python for scripting. No massive virtual environments, just a smaller than 70mb binary needs to be available on my machine. Borkdude FTW.
- maxandersen 9mo ago
  Yes - this is what we need more off - just not only in clojure space. I done https://github.com/jbangdev/jbang-jash https://github.com/jbangdev/jbang-jash for shell processes and smallrye process io also done a lot for nice shell apis. Files access could be another. jbang provides the similar binary - for now bash+jvm based but all simple installable. I have native jbang binaries which are even less than 70 mb :) Definitely going to check out babashka more for inspiration.

WD-42 9mo ago

Looking forward to implementing a AbstractCommandlineParserFactoryBeanServicePatternFactory

gred 9mo ago
> AbstractCommandlineParserFactoryBeanServicePatternFactory ...Locator
maxandersen 9mo ago
it shows you definitely use a certain niche of Java but I hear you on the funny part. When I started showing that its just fine to name a class, `myapp` and run it with jbang myapp.java people got all weirded out. No technical constraints in java; just bad old habits limiting peoples mindset ;)

jen20 9mo ago

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 platform, I'm sure Claude could do a reasonable job of getting a decent chunk of BubbleTea and friends bootstrapped.

gunnarmorling 9mo ago
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 something else. Why do you think is this?
- jen20 9mo ago
  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.
asa400 9mo ago
> That said, if the Java community wanted to port reasonable tooling to their platform, I'm sure Claude could do a reasonable job of getting a decent chunk of BubbleTea and friends bootstrapped. There's a poster upthread who seems to have done what you're describing: https://github.com/WilliamAGH/tui4j https://github.com/WilliamAGH/tui4j

elzbardico 9mo ago

Well, the year is 2003 and I am on a hot dungeon with bad Air Conditioning, figuring out the correct spells for a black magic ant build. A few years later I am writing tons of XML, first for vanilla J2EE, then for spring. We complained, we wondered, nobody cared until one day we decided "fuck that shit, I don't care if ruby is slow as molasses, I just want the pain to go away!" Forgive me if in 2026 I get triggered at the mere mention of the phrase "java build". Lots of us had long relationships with Java, relationships marked by toxicity and abuse. We moved on. Now Java says it is changed, it has matured. Well, it could be true, probably it is even true, but on the other hand, now your toxic ex found out his father, and his name is Larry Ellison.

maxandersen 9mo ago
I guess I should never use Go because I was stuck not having a working debugger, complain about Python because it is single threaded, or javascript because its a typeless mess, or C# for only running on Windows? I'm happy to say I think all have their upsides and downsides and all of them evolve and should all try not to be stuck in old perceptions. And yes Java is held back by those perceptions and I'm saying lets not get bogged down by perceptions like yours from trying to evolve and improve.

TacticalCoder 9mo ago

I've been writing Java utils for the terminal since forever. Mostly because I was extremely familiar with Java. It's never been really slow unless you were loading shitload of classes, like apps that package the entire kitchen sink do or as Clojure does for example. For Clojure now there's Babashka: super quick. And GraalVM compiled Java is more than speedy. Back in, say, 2005, two decades ago, on computers from back then, sure, the java startup time from the CLI were noticeable. But on today's computers? Nowadays when it comes to terminal apps I wrote both Clojure (Babashka), Bash and Java (recently I needed something from a .jar and had no convenient Clojure wrapper and didn't want to bother, so I just wrote my CLI app in Java). Maybe, maybe, maybe that I do feel the startup time when I run my CLI Java app on Raspberry Pis. Raspberry Pi 2 and 3s that is (for I don't have any newer). Startup times aren't an issue. But there may be other reasons to prefer other languages to write CLI apps.

oncallthrow 9mo ago

No, Java (or frankly anything JVM-based) on the terminal is a terrible experience.

gunnarmorling 9mo ago

As a practical example for a Java-based CLI tool in the wild, here's kcctl, a command line client for Kafka Connect: https://github.com/kcctl/kcctl/ https://github.com/kcctl/kcctl/. It's a native binary (via GraalVM), starting up in a few ms, so that it actually be invoked during tab completions and do a round-trip to the Kafka Connect REST API without any noticeable delay whatsoever. Installation is via brew, so same experience as for all the other CLI tools you're using. The binary size is on the higher end (52 MB), but I don't think this makes any relevant difference for practical purposes. Build times with GraalVM are still not ideal (though getting better). Cross compilation is another sore point, I'm managing it via platform-specific GitHub Action runners. From a user perspective, non of this matters, I'd bet most users don't know that kcctl is written in Java.

wcallahan 9mo ago

It just so happens that I’ve built one already: TUI4J (Terminal User Interface for Java). https://github.com/WilliamAGH/tui4j 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 and mouse interactivity parity, showing what this Java library is capable of. Example chat app: https://github.com/WilliamAGH/brief https://github.com/WilliamAGH/brief Would love to see others build similar things with it!

dundarious 9mo ago
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.
- wcallahan 9mo ago
  Great ideas for both :) I wasn’t expecting the main topic of what I’ve been building to appear on the cover of hacker news today, so I was caught a bit unprepared, but they were definitely on the todo list next!
maxandersen 9mo ago
cool - you've hidden that well as I spent a lot of time searching for these. Will definitely check it out. ...where is the jar for brief? :)
- maxandersen 9mo ago
  ah - tui4j is continuation of latte. Cool - now I grok why it looked similar. cool!
  - wcallahan 9mo ago

aoli-al 9mo ago

My biggest complaint about Java development is the state of LSP/DAP support. I’ve tried writing Java in VS Code, and the support is still very incomplete. There are two features I want the most: (1) automatically downloading source code for dependencies, and (2) pausing all threads when a breakpoint is hit (https://github.com/microsoft/vscode-java-debug/issues/722 https://github.com/microsoft/vscode-java-debug/issues/722 ). I can’t find any editor or IDE that comes close to IntelliJ. If we want Java in the terminal, we may also need to think how to write Java in the terminal or are they orthogonal?

maxandersen 9mo ago
hmm - automatic download of source code just works for me in vscode...? "java.maven.downloadSources": true in config if you don't just use maven's automatic download for it. pause all threads does look like a valid omission. Feels like something someone should go contribute - any takers? on your question - I do actually miss having a good an easy java in terminal editing experience. I use a nvim starter pack to do it BUT here there is no good jbang enabled LSP to make it truly smooth ...also on my 2026 wish list :)

timcobb 9mo ago

2026 is going to be the year of learning languages as you review LLM generated code

RickJWagner 9mo ago

Languages lose users when the tooling becomes too heavy. You have to learn ( and maintain knowledge of ) build tooling, unit test frameworks, tools for front end / back end development, distribution and packaging systems, directory structures to accommodate all those, etc. ad nauseum. Then something new and shiny comes out, with much smaller tooling. The lure of easy software construction seduces the user. It never ends.

tgpc 9mo ago

use rust or go, please single binary, no complex deps, ftw

Alifatisk 9mo ago

I wish the article dug deeper into how the workflow would look like in the practical sense when using jBang and jReleaser.

maxandersen 9mo ago
Thats part of what I want to do more of in 2026 and I hoping others will help as otherwise I'll just be sitting in my own quiet echo chamber :)

languagehacker 9mo ago

Will 2026 be the year hammers get a little phillips head on the back in case you run into one of those weird ribbed nails?

binarymax 9mo ago

The question mark at the end is an easy out for us to claim Betteridge’s law.

Eduard 9mo ago
"Does binarymax understand the concept of yes-no questions?"
maxandersen 9mo ago
Yeah, well - I didn't make a factual claim and then questioned it. I asked who is with me? - and no nor yes is not a meaningful answer to that :)

mellosouls 9mo ago

Strangely, not a mention of groovy which I seem to remember was somewhat motivated by use cases such as this?

thomashabets2 9mo ago

I'm not saying we should phase Java out. But it's pretty clear to me that Java was a bad experiment in almost every aspect, and we should at least not add new use cases for it. So no. No, please god no, no Java in the terminal. More ranting here: https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experiments.html https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim...

ktpsns 9mo ago
And yet Java is more then Java. There are lots of more modern languages on the JVM. The ecosystem is huge and still has lots of inertia.
- thomashabets2 9mo ago
  Yeah. Some of my critique applies to the language, some on the JVM and thus cross language. Kotlin sure is less awful, for example. But the JVM, as I describe, was always a failed experiment.

wolfi1 9mo ago

how about jshell? it comes with every java distribution

tpoacher 9mo ago
yes I thought this was going to be about jshell too. jshell is amazing, I don't think enough people know about it!
wewtyflakes 9mo ago
Shameless plug for jshelled (jshell for gradle projects) https://github.com/gravitation1/jshelled https://github.com/gravitation1/jshelled

bfung 9mo ago

Article meta comment: show me, don’t tell me. No show —> not easy enough —> too lazy to look it up, already got python/go/ruby quick cli methods. LLM generated even easier.

martylamb 9mo ago

I spent a long time caring about JVM startup time and CLI suitability (and wrote nailgun [0] over 20 years ago and jsap [1] shortly after specifically because of it), so it's pretty wild to see how far things have come. Modern JVM startup speed and GraalVM native-image have eliminated most of the old excuses. jlink+jpackage help a lot with distribution, and JBang takes it to another level. I've used JBang before but still learned some new tricks from this post. Honestly, it feels like what JNLP/WebStart should have evolved into. I'm not convinced that requiring users to already have JBang installed is the best adoption strategy. But a native package that pulls in JBang if needed and drops a shim launcher/desktop shortcut seems like a natural approach and maybe a fun project. On the TUI side, java could really use something as approachable and pretty as go's Charmbracelet [2]. Once developers regularly see compelling java TUIs in the wild, it'll change their perception. The tooling is here, or at least really close. At this point, it's mostly outdated opinions holding java back in the terminal. [0] https://martiansoftware.com/nailgun https://martiansoftware.com/nailgun [1] https://martiansoftware.com/jsap/ https://martiansoftware.com/jsap/ [2] https://github.com/charmbracelet https://github.com/charmbracelet

slowmovintarget 9mo ago
Strokes chin inquisitively in Babashka... hmmm... Edit: Heh... https://rattlin.blog/bbgum.html https://rattlin.blog/bbgum.html
- martylamb 9mo ago
  That's a cool approach!

ninth_ant 9mo ago

I get the argument from this article that it’s possible. But I don’t get the argument that this is somehow desirable. Just because it’s possible to smash a square peg into a round hole doesn’t make it a good idea.

ivan_gammel 9mo ago
The argument is probably that it’s no longer square.
maxandersen 9mo ago
I'm definitely not going try to force it upon those who don't like java - but I'm saying that the Java peg is way more round than most believe so don't just start using another slightly round peg like python, go, javascript etc. because others said its required :)

nathell 9mo ago

Java in the terminal works exquisitely well already, and it’s called Babashka. Clojure rocks, Bash reaches, and Java provides a rock-solid foundation.

newsoftheday 9mo ago
It sounds Russian, no thanks.

CamouflagedKiwi 9mo ago

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 'pretty' language to write things in. Java has never been something that I have ever wanted to choose, and far, far less so when there's a big hill to climb like this. I guess I fundamentally disagree with all the statements in the article like "This needs to change". I don't think it does. I would much rather than people wrote CLIs in Go or Rust than Java, 100% of the time the latter has been more painful for me to consume.

jazzyjackson 9mo ago
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.
unlikelytomato 9mo ago
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.
- CamouflagedKiwi 9mo ago
  Right, as I said I also think Python has similar issues with startup time. I've used a limited amount of Java CLIs, the most obvious ones are things like Gradle which never felt snappy to use - it is annoying when even doing basic things takes 2+ seconds. I guess not the end of the world, but that seems suboptimal to me compared to a system that feels fast to use and hence well engineered.

nailer 9mo ago

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

thangalin 9mo ago
> 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.
- nailer 9mo ago
  It’s not a generalisation. I am a specific individual relating my own experiences. I have no idea what your app is and have had zero reason to use it.
gunnarmorling 9mo ago
It's a non-issue with GraalVM native binaries. See https://news.ycombinator.com/item?id=46445989 https://news.ycombinator.com/item?id=46445989 for an example: this CLI tools starts in ms, fast enough you can launch it during tab completions and have it invoke a REST API without any noticeable delay whatsoever. But also when running on the JVM, things have improved dramatically over the last few years, e.g. due to things such as AOT class loading and linking. For instance, a single node Kafka broker starts in ~300 ms.
- cb321 9mo ago
  Time comparisons are (or should be) relative. https://news.ycombinator.com/item?id=46447490 https://news.ycombinator.com/item?id=46447490 graalvm is literally 500x more overhead than a statically linked dash script. Maybe not an issue for terminal UIs, but the article mentions both TUIs and CLI tools. A lot of people use CLI tools with a shell. As soon as you do `for file in *.c; do tool "$file"; done` (as a simple example), pure overhead on the order of even 10s of ms becomes noticeable. This is not theoretical. I recently had this trouble with python3, but I didn't want to rewrite all my f-strings into python2. So, it does arise in practice. (At least in the practice of some.)

idkana 9mo ago

[dead]

newsoftheday 9mo ago

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

oftenwrong 9mo ago
You can do better now: #!/usr/bin/env java --source 25 void main() { IO.println("Hello, World!"); } https://openjdk.org/jeps/330 https://openjdk.org/jeps/330 https://openjdk.org/jeps/458 https://openjdk.org/jeps/458 https://openjdk.org/jeps/512 https://openjdk.org/jeps/512 I often combine these approaches with https://get-coursier.io/ https://get-coursier.io/ when I need to fetch third-party dependencies.

pregnenolone 9mo ago

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.

deleted 9mo ago
[deleted]
maxandersen 9mo ago
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. Love you too. 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. Check - agreed. Now, let’s consider how this process looks in Java....<rant> It feels like you missed the last 5 years of improvements..so let me show you how this works in java when using jbang: You download JBang, and immediately have all the tools needed to manage dependencies, write applications, and run other Java applications with a simple command. Since you probably don't believe me I'll show you some of it here: `jbang init -t cli hello.java` - you get a hello.java that declare picocli dependencies and you can run it as `./hello.java`, you even do `jbang app install hello.java` and just use `hello`. You can do this with your own scripts, preexisting jars or existing Maven artifacts. - yes it will also have downloaded right JDK for you; you can easily swith to other versions, either `jbang --java 25 hello.java` or even `jbang --java 8 hello.java` if you really wanna go back in time :) The java version can be baked into your script or jar so it is NOT a requirement for your end user to be aware. `jbang edit hello.java` will offer to install vscodium based IDE that gives you an IDE environment to write java in. `jbang export fatjar hello.java` gives you a runnable fat.jar `jbang export maven|gradle hello.java` gives it a full blown maven/gradle if you are forced to be Enterprise Compliant :) You can even run and distribute these sources by just commiting to a github repo and just do `jbang <repourl>` or use jbang catalogs etc. Lots of opportunities. Reading this and reddit thread I see that the final publish of jars/executables is still too tedious I'm going to try solve that challenge as we have all the pieces (IMO) with jbang/jreleaser and modern JDKs. 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. don't play well with upx - how so? yes there is the usual upx overhead but "just works" when I tried using it? about graalvm native - definitely not going to say its perfect nor easy; but Quarkus definitely have a whole ecosystems of java libraries and framework setup that just works when using native builds. That said - I think we dont need to go to full native for lots of usecases. 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. Yeah, I couldn't wait for JDK developers to do it so I built jbang to make that available today.

cb321 9mo ago

Haven't checked graalvm in a long time. So, I got graalvm-jdk-25.0.1+8.1 for x86_64. It's a lot faster than Julia, and maybe 43ms is not slow in "human terms", but it's still pretty slow compared to some other competition. This was for a helloworld.jar [1]. On my laptop (i7-1370P, p-cores) using tim[2]: $ tim "awk '{}'</n" 'tcc -run /tmp/true.c' 'perl</n' 'py2</n' 'py3</n' 'java -jar helloworld.jar>/n' 97.5 +- 1.5 μs (AlreadySubtracted)static dash Overhead 94.9 +- 3.2 μs awk '{}'</n 376.7 +- 4.6 μs tcc -run /tmp/true.c 525.3 +- 2.7 μs perl</n 3627.7 +- 6.0 μs py2</n 6803 +- 11 μs py3</n 42809 +- 71 μs java -jar helloworld.jar>/n Also, probably there is some way to tune this, but it used over 128 MiB of RSS. [1]: https://github.com/jarirajari/helloworld https://github.com/jarirajari/helloworld [2]: https://github.com/c-blake/bu/blob/main/doc/tim.md https://github.com/c-blake/bu/blob/main/doc/tim.md

NovaX 9mo ago
That is just a normal JVM with optional Graal components if enabled, but not being used. The default memory allocation is based on a percentage of available memory and uncommitted (meaning its available for other programs). When people mention Graal they mean an AOT compiled executable that can be run without a JVM installed. Sometimes they may refer to Graal JIT as a replacement for C1/C2 available also in VM mode. You are using a plain HotSpot VM in server mode, as the optimized client mode was removed when desktop use-cases were deprioritized (e.g. JWS discontinued).
- cb321 9mo ago
  You are correct and I apologize for the misimpression. `native-image -jar helloworld.jar helloworld` did take a whopping 17 seconds to compile, what might be the smallest possible project. That does makes me worry for iterations trying to get better perf in a context where startup overhead matters, BUT the executable it produced did run much faster - only about 1.8x slower than `tcc -run`: 97.0 +- 1.7 μs (AlreadySubtracted)Overhead 98.2 +- 2.8 μs awk '{}'</n 376.4 +- 4.4 μs tcc -run /tmp/true.c 527.9 +- 4.0 μs perl</n 686.5 +- 3.9 μs ./helloworld>/n Perl has 2 more shared libraries for ld.so to link, but is somehow faster. So, there may still be some room for improvement, but anyway, thank you for the correction. (Also, I included 4 of the faster comparative programs to show additionally that the error bars are vaguely credible. In truth, on time shared OSes, the distributions have heavier tails than Gaussian and so a single +- is inadequate.) -- EDIT: So, the ld.so/dynamic linking overhead was bothering me. I had to get a musl + zlib build environment going, but I did after a few minutes and then found this result with a fully statically linked binary executable: 398.2 +- 4.2 μs ./helloworld-sta>/n (I should have noted earlier that /n -> /dev/null is just a convenience symlink I put on all my systems. Also, this is all on Linux 6.18.2 and the same CPU as before.) Also, only around 4.2 MiB of RSS compared to ~1.8 MiB for dash & awk. So, 2.4x the space and only ~4X the time of static awk & dash. That might sound like criticism, but those are usually the efficiency champs. The binary size is kind of hefty (~2x like the RAM use): $ size *sta text data bss dec hex filename 2856644 3486552 3184 6346380 60d68c helloworld-sta So, I guess, in 2026, Java start-up overhead is pretty acceptable. I hope that these "real numbers" can maybe add some precision to the discussion. Someone saying "mere milliseconds" just does not mean as much to me as 400 +- 4 microseconds, and perhaps there are others like me.

tylerchilds 9mo ago

Going to be honest Absolutely shocked Java wasn’t in the terminal I know I don’t use it, but wow. Honestly, super impressed that that they’ve got the traction they do without it but, I think the takeaway is that Java developers like having everything in the IDE— so I’d imagine agentic in the ide will yield higher returns than switching modalities

maxandersen 9mo ago
There is already a lot of Java in agentic systems and IDE integrations — but that alone won’t break the stereotype. The real blocker isn’t capability, it’s perception: many people stop before even trying Java in the terminal. All while Python/JS are seeing a surge in terminal tooling, despite similar (or worse) startup cost, dependency sprawl, and multi-GB installs — and the reaction there is often “this is fine, let’s ship and use.” Until Java is visibly normal in the terminal, agentic features in IDEs won’t change that mental model.

weinzierl 9mo ago

It is not only the language but also the mindset and culture. When in Java System.exit() and even System.println() are treated as smells and I have to actively push to get exceptions from the company wide style I'll just write Rust and be done.

ivan_gammel 9mo ago
Company wide styles that restrict things generally rather than putting them in context are bad smell itself.
maxandersen 9mo ago
Thats my whole point in my blog - we need to change the mindset. Other ecosystems just have much less "enterprise rules" applied to them - break free :)

0xCAP 9mo ago

Let's hope not.

aap_ 9mo ago

Java feels like the COBOL of our times, and the JVM like the IBM 360 architecture.

maxandersen 9mo ago

Author of blog here - this was posted just as I started eating my New Year Dinner - Happy New Year :)