Live data from Hacker News

2026: The Year of Java in the Terminal?

xam.dk

171–180 of 191 posts

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

#171

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 binarie…

[deleted]

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

#172

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 binarie…

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

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

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

#173

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.

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 :)

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

#174

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

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 :)

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

#175

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

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.

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

#177

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 a…

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.

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

#178
post #24

Looking forward to implementing a AbstractCommandlineParserFactoryBeanServicePatternFactory

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 ;)

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

#179

Earlier quoted context omitted.

just because Oracle stopped distributing JDK's is not the same as not possible. Anyone can step up to do this. https://github.com/psumbera/solaris-openjdk seem to work?

I never said it was impossible. I said they dropped support.

ok, but what practical implications does it has?

Pretty sure many other runtimes aren't exactly supported on all platforms by single vendor/projects?

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

#180
post #168

Earlier quoted context omitted.

jbang install does the same. Not enough for you?

I never came across it. I never used anything that installs with jbang, and I bet Im not alone. Most devs have npm installed always, I don't like it but its effective at delivering software to my development environment.

yes, so now you know it exist - give it a try :)

and yes, works on npm, uvx, etc. too.

`npx @jbangdev/jbang`

Post reply on HN