maxandersen

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

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

`npx @jbangdev/jbang`

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

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.

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

Other ecosystems just have much less "enterprise rules" applied to them - break free :)

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

Then when I had ability to write java scripts with dependencies, we added auto download of JDK and then made it so could run any jar (not just scripts) and I suddenly now have full debug support for anything I do + I can install and run this on any docker container or laptop - even my parents or a library computer running some ancient windows. Try that with npm and python :)

All I'm saying - I hear you and I grok why. What I'm saying that for at least close to 5 years at least last 3.5 years there been a way to use the jvm as easy and more reliable than python/nodescript/typescript....run cli's, swing/jfx, backend apps etc.

And in 2026 I want to make java TUI's a reality.

Will definitely check it out.

...where is the jar for brief? :)

So will we see python stop being used?

No, because instead of sitting in corner and mope about it the ecosystem just kept working and filling in the gaps.

Java ecosystems done lot of that - but general public keep having the old changes stuck in their mind.

Lets change that :)

https://github.com/psumbera/solaris-openjdk seem to work?

Even Eclipse and Intellij ship openjdk based runtimes with their distributions and have even stricter GPL limits.

jbang is to java, what uv(x) is to python and what npm/npmx is to javascript.

I haven't really had the burning need for app+jvm since I used graalvm and made jbang and its now trivial to run app + shared jvm for me - but I can see the utility for it.

Noted down the various pointers and existing attempt to explore in 2026 !

About build and publishing - this I feel is also solvable.

Especially if we stop trying to solve it for all possible mutations of gradle/maven builds and just make it work for jars...this is where jbang/jreleaser really simplifies more than I think many realize.

So in 2026 I'll definitely try get more recipes published on this and also see if we can make something like `jbang publish` "Just Work"

There are some extra trickery around ruby gems needing a virtual env to run reliably - but definitely open to adjust/provide needed hook in Jbang if not already present if anyone wants to take a stab at it.

one thing not mentioned is that you can already just do ‘jbang run@jruby’ and run jruby directly if you wish.

At a time I looked into enabling more native jruby support so like jbang can run Java, jsh, groovy and kotlin add first class support for jruby and gems.

If someone interested and know about how to package ruby apps in a jar + addditional files that would be all doable.

And other option is how graalpy provided integration allowing use of //PIP to install packages.

Just ping if interested :)

With this new feature, you can easily prototype new ideas without worrying about the low-level details of application development. Whether you're a seasoned developer or a beginner, JBang's GPT integration makes it easy to turn your ideas into reality.

So what are you waiting for? Give it a try and see what amazing applications you can create with JBang and GPT!

(Yes - this was generated by ChatGPT :)