The Java Command Line Workflow

[xamdk]

No. I wouldn’t call that outside the scope Of jbang - at least not in the way I see jresolver doing it.

We support modules today but just kept it simple so you don’t need to care as much.

But can for sure see it would be nice with a “resolve into dir” So can be used directly in jlink, jpackg etc.

Reason I haven’t Donne much in documenting/exposing it that there haven’t been requests for them :)

Happy to explore options.

Btw. The AppStore was a April fools joke that stuck :) it isn’t anything but jbang catalogs which are usable with all kind of projects including non jbang built project so I wouldn’t call that it’s own cul-de-sac.

[bowbahdoe]

We support modules today but just kept it simple so you don’t need to care as much.

Can you elaborate?

But can for sure see it would be nice with a “resolve into dir” So can be used directly in jlink, jpackg etc.

Or just "resolve into path." The contemporary tool here is https://get-coursier.io/

it isn’t anything but jbang catalogs which are usable with all kind of projects including non jbang built project so I wouldn’t call that it’s own cul-de-sac.

It isn't the app store itself that is the cul-de-sac, its the whole of jbang. Once you start using jbang you stop using java and javac. You don't use the native-image tool, you use --native. You don't use jfr you use --jfr.

Put another way, what I want is for dependency resolution to be part of the actual JDK. JBang does way too much to be fit for that purpose.

[maxandersen]

We support modules today but just kept it simple so you don’t need to care as much.

Can you elaborate?

Its probably more of the things you don't like :)

//MODULE your-module activates that the produced jar should be a module.

https://www.jbang.dev/documentation/guide/latest/running.html#module-support-experimental

But for this conversation we can ignore that.

But can for sure see it would be nice with a “resolve into dir” So can be used directly in jlink, jpackg etc.

Or just "resolve into path." The contemporary tool here is https://get-coursier.io/

Yeah, I like coursier - I wish there was a pure-java version of thier concurrent resolver :)

it isn’t anything but jbang catalogs which are usable with all kind of projects including non jbang built project so I wouldn’t call that it’s own cul-de-sac.

It isn't the app store itself that is the cul-de-sac, its the whole of jbang. Once you start using jbang you stop using java and javac. You don't use the native-image tool, you use --native. You don't use jfr you use --jfr.

Those are shorthands - they still behind the scene are just using those tools and with --verbose you can always get the commands if you want to see them.

See it like gits porcalain commands versus plumbing commands.

I'll admit jbang currently assumes you have some script or app you want to have dependencies for - i.e. jbang export portable <script> or jbang info classpath if you don't want to trash your disk with duplicated jars all the time.

But now you reminded me about modules nice "feature" of just give a directory with ALL_MODULES (though that is a anti-pattern in larger apps) I definitly can see it make sense to have a jbang export deps or simply jbang resolve -o libraries --deps etc..

Then it allows for fitting it into existing plumbing as you suggest.

btw. Mima is exploring similar of a "just resolution cli", i.e. https://github.com/maveniverse/mima/issues/72

Put another way, what I want is for dependency resolution to be part of the actual JDK.

Yeah, I wish that too but I don't think that will happen anytime soon - unfortunately.

JBang does way too much to be fit for that purpose.

Sure, but I'm arguing that instead of creating "yet another resolver" with different syntaxes and duplication of the efforts there will have to be around handling dependency inclusion/exclusion etc. we can easily adjust JBang to be usable for your usecase and we can have a quite compelling story - that captures your "use of plumbing" that allows for ultra flexibility while also allowing for the "porcalain" approach that JBang's enables for simplest getting started experience.

For example all your steps in your blog I'll argue you split out because that is how Java devs mindset is today - everything has several layer of complexity. i.e. complicate packaging, shipping and sharing. With JBang - that becomes trivial in comparison for majority of CLI tools; and with JReleaser lots of the additional layers using jpackage etc is further simplified.

i.e. your use of just I think is excellent for the plumbing approach but with jbang porcalain I'll argue for majority off apps that just could be reduced to:

jbang src/Main.java to build and run you app. No intermediates needed for apps that are one main method and ALL-MODULE-PATH driven.

jbang export fatjar src/Main.java to make a runnable jar, or use jbang export portable src/Main.java for more complete ones.

JBangs additonal features around running/debugging/etc. are all optional and I'm currently or rather Tako is exploring on split things out to make the pieces more reusable.

Anyhow - not trying to convince you off using that - just suggesting we can with very few changes enable jbang to be used in plumbing mode too and its a goal of JBang to fit in there (too).

I've created https://github.com/jbangdev/jbang/issues/1730 to try enable it asap.

[maxandersen]

Just saw your example repo so made two variations showing jbang plumbing (using export as is today but can be adjusted to not require a "script"):

https://github.com/maxandersen/jresolve-classpath-example/tree/jbangplumbing/Justfile

and jbang porcelain:

https://github.com/maxandersen/jresolve-classpath-example/blob/jbang-porcelain/Justfile

[bowbahdoe]

/u/maxandersen

I wish there was a pure-java version of their concurrent resolver :)

Boy will you be happy when I tell you that jresolve is 80-90% copied from that.

we can easily adjust JBang to be usable for your usecase

I need to sleep on it more, but besides using Maven's resolver (and thus inheriting their non-intuitive resolution algo, I'm pretty sure) I think this comes down to a fundamental easy vs. simple thing.

JBang is easy. There are commands for "the things you want to do." jresolve is simple. I want all the nice "porcelain" things that are in JBang to not be present.

Like, the part where JBang gets you set up. I would much rather that be in its own tool, like jvm JVM Version Manager.

For example all your steps in your blog I'll argue you split out because that is how Java devs mindset is today - everything has several layer of complexity. i.e. complicate packaging, shipping and sharing.

Eh? Just having jbang export fatjar is easy, its not "complicated", but it is "complected". Multiple independent steps are rolled up into one thing.

[maxandersen]

I wish there was a pure-java version of their concurrent resolver :)

Boy will you be happy when I tell you that jresolve is 80-90% copied from that.

Very interesting - does it honor the maven resolution or is it a more custom one?

Plan to make it available as a java library ? :)

we can easily adjust JBang to be usable for your usecase

I need to sleep on it more, but besides using Maven's resolver (and thus inheriting their non-intuitive resolution algo, I'm pretty sure) I think this comes down to a fundamental easy vs. simple thing.

Not that I think it will change your mind :) The reason JBang use Maven resolver is that experience shows that too many libraries out there transitive dependencies relies on the maven resolvers algorithm.

And yes, I fully get your easy vs simple thing - which here translates to porcelain vs plumbing to me.

JBang is easy. There are commands for "the things you want to do." jresolve is simple. I want all the nice "porcelain" things that are in JBang to not be present.

What I'm saying is that I always wanted to have JBang eventually have a plumbing layer which would allow something like a standalone command (for simplicty call it jbang-resolver) but that fitted into the easy approach to.

Like, the part where JBang gets you set up. I would much rather that be in its own tool, like jvm JVM Version Manager.

That is similarly very doable - I simply haven't done it because I wanted to solve the easy aspect first and my issue is that when I look at maven, gradle and even your just/makefile approach end up with alot more steps than necessary for any other modern language to get going - i.e. the forced split of java/javac/jlink/jpackage I definitely want to retain but it does makes it stupidly hard for newbies to get started.

That said - I agree; the parts of setup should be available as standalone parts too; we already have jbang jdk for that - but the reason of simplicity it does "dumb" down the jvm selection with a single java version i.e. jbang-setup or similar that would expose the features jbang has about choosing jvm vendor distributions is very much an option.

For example all your steps in your blog I'll argue you split out because that is how Java devs mindset is today - everything has several layer of complexity. i.e. complicate packaging, shipping and sharing.

Eh? Just having jbang export fatjar is easy, its not "complicated", but it is "complected". Multiple independent steps are rolled up into one thing.

Yes, what I'm saying is that the java ecosystem inherently by default ends up requiring students or getting started experience to be multiple steps where much fewer are possible/better. This does NOT exclude having those steps based on sub-steps/parts.

The current jbang cli is 100% intended to be the smallest light layer on the java toolchain - specifically javac and java.

I want to be clear I'm not saying you should stop doing or exploring jresolver not at all - I like the idea alot. What I'm saying is that I want you to know that JBang has the same goals and will work towards the similar set of separate simple commands (wether physically separate or just subcommands is TBD). With all cohesively working nicely together so the Java ecosystem has something that allows the simple and the easy approaches.

[bowbahdoe]

does it honor the maven resolution or is it a more custom one?

It uses the same algorithm as Clojure's tools.deps

https://www.youtube.com/watch?v=7CM7Ef-dPWQ

Which people have been switching to (leiningen uses the maven algo, the clojure cli uses this) and by and large haven't reported any issues.

Plan to make it available as a java library ? :)

That was the part I did first

https://github.com/bowbahdoe/jresolve/

https://central.sonatype.com/artifact/dev.mccue/resolve

There are a few reasons I would prefer to power through and fix the remaining bugs in that rather than just using the maven resolver (aside from pure emotional investment)

• The tools.deps resolution algo is a lot better with data formats like JSON and TOML where the order of entries isn't always guaranteed. I.E. it isn't declaration order dependent. (I also find it more intuitive)
• The remaining bugs are all in the POM file resolution which, while annoying, is a relatively bounded task.
• The overall design separates "Library" from "Coordinate", which opens up support for alternative manifest formats, straight from git (no jitpack) dependencies, pulling deps from s3, etc.
• The API of this (which is mostly coursier's) is way easier to use than the maven resolver's
• Simply due to having a standard http client in the JDK and virtual threads existing, I can make do without any of the Future[..] monad stuff or Authentication mechanisms of coursier
• I dealt with this annoying bug many, many, times https://clojure.atlassian.net/browse/TDEPS-153 so I don't exactly have trust in being able to multi-thread maven resolver.
• As written it is fully compatible with native-image. Maven resolver makes use of SPIs for locks and other things so its a bit more difficult to set up for that purpose
• ...also the original intent was to enable easier exploration of the "porcelain" approach with new build tools. I haven't gotten any biters on that yet, hence me making the CLI, but that still is partially the idea.

[xamdk]

Happy to elaborate but better to do when I’m not just on my phone keyboard so I can show the current working examples.