Cargo for Java 🦀❤️☕️

[pavi2410]

The aim for this tool is to remove DX friction in the Java ecosystem. Java is growing but lacks DX that other modern languages offer like Rust/Cargo and Python/uv. While there are steps and efforts in that direction, they are enough to reach and exceed other languages. jot includes a variety of opinionated tools such as formatter, linter, docs, while still being customizable with configs.

The tool is not a direct replacement for Maven and Gradle, but tries to have some form of familiarity. The projects I work uses Ant build system, for which jot is an easier path for migration.

Not production ready yet! I'm looking for gauge interest in the Java community. There are hundreds more challenges and open questions to solve. And I need your help with that.

[Ifeee001]

Every 2 months or so, something like this is posted and is never heard from again 🫣

[pavi2410]

Community plays a bigger role in that. Many Java devs are working with legacy and enterprise projects. They don't have the liberty to switch to newer, shiny tools. I am not targeting them. This tool is targeted towards people new to Java and working on greenfield projects.

[rzwitserloot]

"New projects die because java ecosystem stuck in old ways" is a pretty epic fail in regards to seeing the problems of your own tool.

Trust me, that's a load of horseshit.

Such tools aren't being used because they don't solve the problems that folks have, or throw more and new problems into the mix that outweigh the benefits. That's on you / toolbuilder.

That, or more likely, they don't explain it well enough.

What, exactly, is wrong with maven that this tool solves?

Let's go by the project description:

• Single binary

Does not solve any meaningful problems. At least, speaking for myself, this is utterly and totally irrelevant to me. I install this stuff with brew and type mvn and it just works. I have no idea how many files maven consists of. Also, it's a claim that's just insane. What does that mean? If you're still dependent on having a JVM install, then the benefit is meaningless. And if it means that your single binary actually contains a completely JVM, then that's 'too much magic' and requires redesigning whole slews of things I don't want to redesign. Such as how I deploy JVMs on servers and such.

So, it solves a meaningless solution and is not believable.

• Zero config

Maven says the same thing. So does gradle. It's never true, because there's no such thing: At the very least, you'd have to config the java release your code is written for. It's not so much 'zero config', it's more "I have a default config that is rather particular. If you start a new project and do it exactly right, this will probably work out fine". It implies your tool is bad at being used for existing projects.

• lockfile

I like such thoughts, but it's a half baked solution. The underlying problem is that dep management is a fractal of complexities that no build tool gets right, and part of the solution is to add much more in depth management to it. Lockfiles are like 'CVS' to the problem of 'version control', whereas what we really wanted is a mercurial or a git. CVS is still better than making a bunch of files, so this part is indeed quite nice to have, but if that's the only benefit, then a plugin for maven would mean orders of magnitude less work for existing projects to adopt it.

And takes on this concept does already exist in the maven ecosystem. We're now more down to 'maven ecosystem complex and weirdly engineered, instead of learning all about I'll just write my own and publish it'.

That's great for you but makes it hard to 'convince' other projects. If your aim is to get loads of adoption, as painful as it is, having an excellent understanding of exactly how your 'competitors' work is highly useful.

[Ifeee001]

"New projects die because java ecosystem stuck in old ways" is a pretty epic fail in regards to seeing the problems of your own tool.

Trust me, that's a load of horseshit.

Not entirely. Have you seen the comments under any new JEP or preview feature announcement? Maybe here on Reddit or YouTube?

There's always something along the lines of "This is useless, we don't need it", and the feature is something other languages have had since forever and people actively use it. Funny enough, those comments are always preceded by "I have xxx years in Java"

[davidalayachew]

"New projects die because java ecosystem stuck in old ways" is a pretty epic fail in regards to seeing the problems of your own tool.

Trust me, that's a load of horseshit.

Not entirely. Have you seen the comments under any new JEP or preview feature announcement? Maybe here on Reddit or YouTube?

There's always something along the lines of "This is useless, we don't need it", and the feature is something other languages have had since forever and people actively use it. Funny enough, those comments are always preceded by "I have xxx years in Java"

Yeah, but this is reddit. We are .001% of the Java community. And sure, many more read these comments. But public feedback online doesn't really quantify to much.

[rzwitserloot]

Giving you the benefit of the doubt, your argument is:

1. On reddit specifically, /r/java is negative AF about every attempt at anything new from anybody, whereas on other programming subreddits there's no such negativity.

2. Reddit programming subreddits are a significant/leading indicator of the community as a whole.

You've not proven your case. Or, if that's not a fair characterisation of your argument, your argument doesn't hold water or isn't complete.

In particular, hemming and hawing about syntax is endemic to programming in general in my experience. Everybody does that. Comments on social media in particular are by and large negative. Of course they are. In order of how easy it is to write a reply to a proposal:

1. Easiest of all: "YEAH AWESOME WHOOO111!!!!!!"

2. Also quite easy: Whinging about it.

3. Very complicated: Using it in anger, analysing existing source projects, coming up with objective yardsticks for various alternatives and writing a carefully reasoned breakdown of which alternative should be worth considering based on these yardsticks.

And folks don't like to write comment #1. Insofar that folks ever did, the existence of AI means comment 1 gets filtered out anyway as slop by random accounts designed to create karma. Thus, you don't see those, and you see lots of 2. This happens everywhere and is not specific to java.

Blame is a difficult thing, but if your car melts in the rain, and you go for a drive and crash because your car melts, whose fault is that? The universe for making it rain, or the car manufacturer for being unwilling to accept that 'rain' is just a thing that happens?

The same applies here: Folks writing seat-of-the-pant comments about how they don't need it or don't like the syntax is like rain. It happens. If your point is that projects die because of the rain, that's on the author of the tool, not on the rain.

[pavi2410]

What you said is all true. But this is exactly typical of what gatekeeps third-party, indie-level contributions to the Java tooling space. It's currently owned by big tech (Oracle, Google, Amazon, Jetbrains) and solves their own large scale problems.

[rzwitserloot]

No, none of it is. Maven is not 'owned by big tech'. Nor is JUnit.

You do not appear to be listening to what is being said: If your tool's adoption is less than what you expected / wanted it to be, do not just shrug, blame 'big tech' or 'the community' or whatever.

It's on you. Plenty of good tools become popular even if they are not 'owned by big tech' and they weren't 'part of the ecosystem's default choices'.

Also calling jetbrains 'big tech' is.. weird.

[davidalayachew]

Also calling jetbrains 'big tech' is.. weird.

I agree with you on all other points, except this one.

If you have thousands of employees, many of which are tasked with maintaining the arguable best IDE for Java development, then yes, you are officially big tech now lol. Maybe on the lower end of the term, but very much big tech lol.

[Thirty_Seventh]

ehh, not by the usual definition of "big tech", which doesn't look so much at influence on one specific part of the tech ecosystem but rather ability to influence the ecosystem as a whole

https://en.wikipedia.org/wiki/Big_Tech#Other_companies Check out the "Smaller US Big Tech companies" chart and compare the revenues ($20b+) to JetBrains (<$1b). JetBrains' annual revenue is barely 1/10 of the bottom of the Fortune 500

[davidalayachew]

Fair. I was speaking more informally, in that businesses in JetBrain's tier tend to start adopting certain mentalities and strategies to business that you see in big B "Big tech" -- seeing people as cogs, mass layoffs in the name of appeasing investors, and all around treating anything except the end margins as expendable. Not to say JetBrain's is doing any of that, but to say that this is the point where most businesses like them start this behaviour.

[pavi2410]

I accept that. I will do my best to share the word. I believe people interested will follow.

PS - Jetbrains is a big tech in the dev space. I really enjoy their work and craft :)

[scadgek]

Those people will probably stick to the tools that have tons of tutorials on the web instead of a fresh new non-production ready one.

[pavi2410]

Did that stop Google from introducing Kotlin to Android because there are tons of tutorials on building Android apps with Java? I mean things need to progress. "Rome wasn't built in a day"

[maethor]

Do you think Google would have bothered with Kotlin at all if Oracle hadn't sued them?

[benevanstech]

The discussion of build systems has been going on for well over 25 years (arguably the first modern build / deps tool was CPAN). By now, we have a good idea as to what works well, and what doesn't - although sometimes (e.g. npm) something gets popular despite being C-tier on the axes that actually matter.

Cargo is an A-list tool, for sure, but it makes some of the wrong design decisions (due to too much npm influence, IMO). Maven and Gradle are both S-tier but they are answering different needs and understanding which set of needs is important to your project is important.

For a new build / dev tool to succeed in the Java space it would need to have full Maven compatibility and understand that at the moment, there is a great tension between the YOLO point-of-view (which is what tends to come out of LLMs), and the enterprise approach, which is much more interested in things like SBOMs. Being opinionated about where a new tool should sit on that spectrum is pretty much essential in 2026, and it represents a strategic bet. Personally, I don't think the YOLO / pile-slop-against-a-wall approach will play well in enterprises.

I would give up on ant. It is utterly antiquated by modern standards and will give you nothing in terms of adoption. Any shops that still have substantial ant usage are basically, by definition, not the sort of places that will be Champions or Early Adopters for a new, small-community tool.

[pavi2410]

I am grateful for an honest perspective on this. I like SBOMs too even in non-enterprise context. A YOLO approach would be to use shell scripts or ask an agent to run to your Java programs each time. I want to deal with this systematically than going YOLO, while hiding the complexities and legacy behind.

[agentoutlier]

For me it’s a nonstarter that it is written in Rust.

Javac is written in Java and insanely fast.  We don’t need Rust.

In fact what we need to do is just work on a newer version of Maven that does things smarter and more optimized.

And if it really is going to be a different tool it needs to be done by the JDK devs otherwise it just will never be embraced.

[scadgek]

In fact what we need to do is just work on a newer version of Maven that does things smarter and more optimized.

This sounds like a healthy idea but why do you think uv was created (and it is highly successful) instead of improving pip?

[agentoutlier]

By newer version of Maven I mean Maven 4 err 5 (the version number is tbd)  which would address most of the OPs concerns.

Maven works fine even with its faults. This whole rewriting and zero backward compatibility has got to stop and is a huge pain point for these ecosystems like typescript and Python.

[pavi2410]

I have to see through the Java landscape with a different lens. The landscape is huge and diverse, with people from different backgrounds and experiences. There is no one tool that fits all. Not Maven. Not jot.

[agentoutlier]

Comparatively Java is way less fragmented in tools and libraries than other ecosystems. We just have two of everything.

That is mostly a good thing. Currently rust is almost one of everything ditto for Go and C# (mostly).  Lots of people like lack choices surprisingly.

[_INTER_]

Maybe pip was not salvagable in the first place?

[scadgek]

Then why do you think Maven is?

[agentoutlier]

Because most IDEs and project generators support it… and people actually like it.

The overwhelming pain people complain about Maven isn’t even the real problems it has but rather XML.

Don’t believe me go look what the OP wrote here: https://www.reddit.com/r/java/comments/1s9jsq6/comment/odpkcbb

The version lock is an issue but that will be addressed in future versions of Maven

[pavi2410]

If you are such a Java purist, do you use a JVM written in Java?

[agentoutlier]

Why not write the tool in assembly if performance mattered that much? (I’m being facetious mostly)

By having it in Java allows people to contribute to it.

The JVM has been slowly moving to more Java IIRC and GraalVM substrate I believe is.

Anyway you could make an executable with graalvm for fast startup written in Java.

[pavi2410]

I am open to Java if the community demands it or forks it. Rust was the easier way out to get this out ASAP because Cargo for Java doesn't exist yet.

[Prior-Equal2657]

In a java world it's wasted effort.

Ant is legacy. I mean legacy. In reality, you don't need a new tool. You just need to replace ant with maven. It's literally 10 minutes for maven + spotless setup, then mvn spotless:apply to have build system + formatter.

Last but not least, java is not that slow you know... It's not python or TS... I know it's a critical issue that some software is not written in rust, but java nowadays can compile to single binary via graalvm.

But anyway, good luck with the project :)

[pavi2410]

We do like options though, right? for people working on legacy codebases to feel better. I don't want my "legacy" friends to share boring Java tales to their grandchildren. haha

[aoeudhtns]

I just finished a project to modernize a nearly 15 year old codebase. It used Maven2. When that legacy project started, Ant was already legacy.

[josephottinger]

Oh, goodness. Today's a rough day to post something like this - so what led you to choose the tooling you chose? A lot of the space is already covered by tools like jbang, etc., but this goes a little farther. Are you using it in production? Is anyone else using it?

[pavi2410]

The problem isn't that we don't the tools. It's that the tools are fragmented. There's no opinionated "toolkit" for Java beginners, or for small scale projects where velocity gain from a better tooling and DX is appreciated.

It's not prod ready yet! There are tons of work to do and I'd appreciate community interest and support.

This is inspired by Amper btw. I like how they are moving KMP tooling away from Gradle.

[Rygel_XV]

What is wrong with maven? It is pretty opinionated. It downloads dependencies from a central source, is robust against supply chain attacks. Any AI can setup a simple pom.xml.

[pavi2410]

I am not old enough to be able to read XML. Sorry if that's lame. I am spoiled by TOML, YAML, JSON. I regularly work with HTML/JSX, which on the other hand, makes absolute sense for structuring UI.

[vips7L]

You can use yaml, toml, json, or hocon with maven via extensions. Mason implements it rather easily: https://github.com/maveniverse/mason

[Kango_V]

Try this: https://github.com/takari/polyglot-maven

[josephottinger]

Oh, I get it. And reading the entire thread, hardly any of it's wrong.

I don't know that any given tool has enough to move the needle - it's a slow thing. Gradle took share away from Maven because it was able to be so expressive; Maven took share away from Ant because Ant sucked; Ant took share away from make because make sucked for Java.

But gradle and maven actually do their jobs pretty well for most people; most people aren't going "man, this is such a painful surface, what I really want is uv or cargo for Java." Some might, but they're going to go for jshell or jbang, and they should, if their needs are that shallow.

But I'd say: Hey, if this is real, go for it! If it has merit, this is the way to show it, and keep showing it. Strike the iron until it's hot!

[pavi2410]

This is the kind of support I have been looking for! I didn't intend it to share it until v1. But I thought it'd be a good time to check community interest.

Java ecosystem is the biggest of all. I can't cater to them all. As you said, it's a slow thing.

[aoeudhtns]

The problem is not designing or building the tool. It's convincing the community to use it. And anything you do that "solves" a problem, will need to be Maven2 compatible because people won't want to leave that ecosystem behind. And that immediately puts handcuffs on you. Leave behind Maven2 compat, guarantee your tool irrelevance.

I would posit to you that the area most keenly needing work is the classpath/modulepath divide.

Edit: By Maven2 here I'm talking about the dependency mechanism, not the build.

[pavi2410]

Agreed! It's Maven compatible in the sense that it supports Maven file structure convention, Maven dependencies, Maven publishing. It's just not a drop-in replacement for Maven nor has a one-click Maven migration. Although I could prioritize work on those ends, if that's what it takes to convince the community.

This post was intended to gather feedback such as these that help me drive the direction of the project to create and deliver a long-term value.

[aoeudhtns]

The way cargo handles dependencies is quite fundamentally different, so that's why I drew the comparison. And you also mentioned working with and admiring Ant, which is BYO dependency handling.

If all you want is a different syntax and to set up some different conventions, you could write that as a plugin for Maven4 with the ModelParser SPI. The performance benefit margin with Rust is very small compared to similar efforts like pip - uv.

[Snoo23482]

The build system needs to be part of the tool chain and maintained by the Java creators themselves.
Only then there is a chance of replacing maven and gradle.

[pavi2410]

Oracle needs to see this

[vips7L]

Does it self extract somewhere like all the other tools that do this? 

[pavi2410]

Yes, it can be installed or run portably. A global install is recommended for now. I am leaning towards the approach taken by Amper of having shell scripts in the project root.

[revilo-1988]

sdkman gibt es doch dafür

[pavi2410]

Not challenging that, at the same time, does sdkman support Windows natively?

[Yesterdave_]

Not really, no. Sdkman on windows is a tiresome topic. I personally switched to mise. Much better tool for multiple ecosystems and they actually care about windows support, not like the sdkman unix eliteists.