In my experience, the problem of Java is the lack of standardized tooling.

To build an average Java software, you have to install a specific version of JDK, download a specific build system (Ant, Maven, Gradle, Bazel), hope everything works out on the first try - and if not, debug the most-likely-XML spec file searching for invalid dependency that's printed out on the 1000-line error output...

What Java is desperately missing is something like Python's `uv`.

---

Sibling comment mentioned that debugging Java itself is also a nightmare, which reminds me of the many Spring Boot projects I've had to debug. Stack traces containing 90% of boilerplate code layers, and annotations throwing me from one corner of the codebase to another like a ragdoll...

Admittedly, that's not inherently the problem of Java, but rather the problem of Spring. However, Spring is very likely to be found in enterprise projects.

▲ vips7L 3 days ago | parent | next [-]

I think this is really just anecdotal to your experience. Don’t you need to install a specific version of a compiler or interpreter for every language? Isn’t trying to build any complex project a pray on the first try? I’ve worked in Go codebases where it’s not simply “go build”. It’s: try go build, oops you need to use the make/justfile, oops don’t forget you need to install jq or some other random tool. Complex projects are complex.

▲ Mawr 3 days ago | parent | next [-]

Not at all? There is an obvious difference between modern languages' (Go, Rust, Zig) build systems and the old mess (C++, Java, Python). You have one tool that does everything you need, from formatting and linting to package management and building. No need to choose between Maven or Gradle or try to string together five third party programs that barely work together.

> I’ve worked in Go codebases where it’s not simply “go build”.

A rather funny statement that says the opposite of what you intended. That you can expect most Go projects to be built with just `go build` is high praise.

▲ vips7L 3 days ago | parent [-]

I expect most Java projects to be built with mvn package or gradle build. It doesn’t mean it’s always that simple. Simple projects can be built simply. Complex ones are never handled by 1 tool. There are plenty of examples in Rust and Go where people have to use make or just.

▲ mleo 2 days ago | parent | next [-]

This has been one of my pet peeves on our projects; how simply can I build a project and run it. Ideally with just Java and git, can I download, build and run. Throw in some projects with native libraries, can I build with compiler tools installed but not building 5 other projects first with environment variables pointing to locations of code.

▲ pkolaczk 3 days ago | parent | prev [-]

However, gradle build or mvn install won’t select a proper version of Java to build your code. It won’t even tell you are building with wrong version. Rust, Go, even Scala SBT will.

	▲	ivan_gammel 2 days ago \| parent \| next [-]
		Normally you just define source and compile target and then use whatever JDK supports them. Dependency on exact version is a rare thing. Neither gradle nor Maven are independent native tools, both run on the same JVM they use, so they are not even aware of your specific OS configuration and available JDKs. But they will certainly tell you if your JDK does not support your source or compile target.
	▲	ohdeargodno 2 days ago \| parent \| prev [-]
		> However, gradle build or mvn install won’t select a proper version of Java to build your code. `build.gradle.kts java { toolchain { languageVersion = JavaLanguageVersion.of(17) //bonus: pick your favorite distribution with vendor = JvmVendorSpec.<X> } }` Oh yes they will. > It won’t even tell you are building with wrong version. Right, "Class file has wrong version" doesn't explicitly tell you it's the wrong JDK. Gradle itself runs from a JDK8, so even the install you made with your Windows XP will work fine. If your last experience with Java was 20 years ago and you think that for some reason it hasn't kept up with modern advancement and leapfrogged most languages (how's async doing in rust? virtual threads still stuck nowhere? cool.), sure, keep telling yourself that. You could at least keep it to yourself out of politeness though, or at the very least check that what you're saying is accurate.

▲ bheadmaster 2 days ago | parent | prev [-]

> Isn’t trying to build any complex project a pray on the first try?

I managed to build Docker Daemon - one of the most widely used and complex Go projects - from source with a simple `go build`.

I've never figured out how to build Jenkins from source.

Do you know of any widely used Java project that has a simple build process? Maybe a positive anecdote could change my mind.

	▲	ohdeargodno 2 days ago \| parent [-]
		[dead]

▲ rileymichael 2 days ago | parent | prev | next [-]

> To build an average Java software, you have to install a specific version of JDK, download a specific build system (Ant, Maven, Gradle, Bazel), hope everything works out on the first try

to build a modern java project with gradle, you need _any_ jvm installed on your pc. you execute a task via the gradle wrapper (which is committed alongside the code) and it will download and invoke the pinned version of gradle, which then downloads the configured java toolchain (version, vendor, etc.) if it can't find it on your machine.

it just works.

▲

bheadmaster 2 days ago | parent [-]

> to build a modern java project with gradle [...] it just works.

That's the thing - it "just works" if you're on a "modern" Java project, if it uses Gradle, and if it uses it properly. Most of the Java projects I've had pleasure on working profesionally were not on that standard of quality.

You may argue that it's up to developers to keep build system simple, but in that case C++ tooling also "just works" because you can build a modern C++ project that uses CMake in two commands.

Good tooling prevents the project build process from becoming an undocumented Rube Goldberg's machine.

	▲	ohdeargodno 2 days ago \| parent [-]
		[dead]

▲ maksut 3 days ago | parent | prev | next [-]

I disagree with this. The tooling around JVM is great or at least good enough.

Maven is mostly smooth sailing comparing to Python's env solutions or JS ecosystem. Maven is 21 years old. A quick search says Python has/had; pip, venv, pip-tools, Pipenv, Poetry, PDM, pyenv, pipx, uv, Conda, Mamba, Pixi.

Debugging is just fine. Modern debugging tools are there. There is remote debugging, (although limited) update & continue, evaluating custom expressions etc. I don't know what they complain about. If using Clojure, it is also possible to change running application completely.

Monitoring tools are also great. It is easy to gather runtime metrics for profiling or monitoring events. There are tools like Mission Control to analyse them.

▲ ojosilva 3 days ago | parent | prev | next [-]

Python is a front-end for C, like Perl, PHP and Ruby. Its environment configuration is a mess, specially if you need to recompile libraries with different python versions.

Java may have a long history of compatibility issues between the compiler, tooling and libraries, but it's all reasonably delimited to the Java language, so, if anything, a `nvm` equivalent such as sdkman.io should suffice.

▲ theanonymousone 3 days ago | parent | prev | next [-]

> What Java is desperately missing is something like Python's `uv`.

JBang exist and (if I'm not mistaken) predates uv. See jbang.dev

▲ pjmlp 3 days ago | parent | prev | next [-]

We don't need Rust written tools in Java.

▲ Phelinofist 3 days ago | parent | prev | next [-]

I totally disagree, please don't add something like envs to Java, ever. Working with Python is a huge pain because of that. Also, mostly just a JDK that is new enough, because of the strong backwards compatibility of the Java ecosystem.

▲ ivan_gammel 3 days ago | parent | prev [-]

Spring does some magic, but I cannot agree with you that it is hard to debug. Maybe if you don’t understand it at all, but its architecture isn’t rocket science.