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.

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.

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.

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.

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.

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.

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

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.

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

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

We don't need Rust written tools in Java.

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.

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.

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.

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

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