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

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.

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.

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.

Regarding UpX: it simply doesn’t work with Windows binaries generated by Graal – see this issue: https://github.com/oracle/graal/issues/7605. They've been ignoring this for three years instead of fixing it. Meanwhile, it works perfectly with Go binaries or .NET’s AOT compiler. I’m not trying to bash your project, but the reality is that no one with little to no Java experience is going to discover and install jbang. Features like this should be included with Java out of the box.

and still npm, python, and other ecosystems don't do that. they effectively ships what corresponds to jars with dependency metadata.

I also did not say fat jars (even though that works fine too).

Why don't java world be ok with utilizing that option like other ecosystems.

I know why they didn't do it in past when something like jbang did not exist - just like javascript didn't do it before npm (and fast node runtime) came around...

I’ve brought up numerous complaint regarding jpackage and jlink, and none of them have been addressed by jbang.

I explicitly wrote: "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." so I did not claim jbang solves it - I said I could see how it could be better.

What I did show or at least tried to was that your complaint about something like scala-cli and how Go could do all things out of box...jbang exist to bridge that gap.

Furthermore, you accuse me of not having used Java in the last five years, which is frankly ridiculous;

I did not claim that at all. I said you seem to have missed the last years improvements in this space (jbang being a key one enabling majority of the issues you brought forward).

I've spent almost two decades developing software on the JVM. Funnily enough, I had to write my own sbt plugins because jlink and jpackage are so painful to use.

yes, I agree jlink and jpackage is not good enough.

I haven't tried tackle it yet as I used jreleaser most of time to hide that pain - and I agree its not solved yet...but also trying to show that distributing everything as native OS binaries is NOT an absolute requirement and not what other ecosystems does.

Heck, even Go allow for running git repos by compiling it locally before running it... jbang allow similar workflows - on top of plain java.

Regarding UpX: it simply doesn’t work with Windows binaries generated by Graal – see this issue: https://github.com/oracle/graal/issues/7605. They've been ignoring this for three years instead of fixing it. Meanwhile, it works perfectly with Go binaries or .NET’s AOT compiler.

gotcha - haven't tried it on windows for a while and looks like it did work in GraalVM 21 and just issue on future versions.

I’m not trying to bash your project, but the reality is that no one with little to no Java experience is going to discover and install jbang. Features like this should be included with Java out of the box.

yeah - well neither node, python and others had these to begin with.

Its a very Java'esque mindset to require it in the default toolchain to be considered useful.

I wonder why anyone even still try using maven or gradle or sbt - it does not come with Java itself either :)

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

Lets please not mix up good dev flows with end user flows...this is not unique problem for java.