The different JDK builds are almost all built from OpenJDK. Maven and Gradle cover nearly all use cases. The complexity is not that high.

▲

giobox 2 days ago | parent [-]

I think it is quite high, especially for newcomers to the ecosystem. The popular sdkman CLI tool for managing JDK installations provides 17 different JDKs to install:

https://sdkman.io/jdks/

With the DotNet SDK for comparisons sake, there is but one provider, and package management is provided as first class citizen in the compiler CLI, removing the need to even pick a "gradle" or "maven" style build tool in the first place for almost any project.

▲

Eldt 2 days ago | parent [-]

At the very top of the page it mentions a default which kind of negates that issue...

	▲	giobox 2 days ago \| parent [-]
		It doesn’t negate the issue at all, especially as sdkman is an optional extra tool. If working with others, that default is not always going to be the one your team develops against either. If you are just trying to pick a jdk and don’t even know sdkman exists, a sensible person will rightly wonder why the ecosystem has fractured into 17 JDKs, or you won’t notice at all and blindly pick a download from the oracle website. I’ve seen it cause confusion many times for new (and old!) Java developers. Checking a new developer has actually managed to install the correct JDK for a given project is still a thing I have to do, all the time. Sdkmans docs also have no bearing on the multiple build systems in the java world too, which again simply a non-issue in DotNet and many others.