Clearly you haven’t been part of the group that had to track down where Java could be installed in a jumble of workstations and servers, because it was installed as part of an application that may or may not have advertised Java as its third-or-fourth level dependencies.
It also seems you are forgetting just how bad early Java was, from a programming and user standpoint. Java errors like NullPointerException became a meme because they were so prevalent in user space, and required so much energy and time to get things working. As a result, people typically refused to update any part of Java once their app was working, to avoid breaking things. And that was _if_ the install was registered with a package manager or Windows Update so updates could be reported.
As someone who supports Java apps, I don't think the errors have improved. They are completely nonsense to non-programmers, and they rarely ever have good documentation. Most only show up in old SO post, or application specific forums, and you have to sift through a ton of crap just to hopefully find an explanation or fix.
But what is it about Java errors specifically that make this a "java" problem as opposed to a "bad developers" problem? What makes "FileNotFoundException" more non-sensical to non programmers than "SEGFAULT" or "Error -256". Maybe you could argue that the stack traces and "let it bubble" behavior is useful to developers and as a result developers don't write better error handling to translate those errors into better user facing errors, but again that feels like a developer problem, not a language problem.
What does it have to do with java though? It’s a programming language, not general artificial intelligence. If you wrote errors that suck, and then didn’t bother encapsulating it in some sane form before it hits the user, it’s entirely on you.
Java is decent enough that even when that happens, the log/stderr will at least be actionable by devs, which is much more than many other ecosystem can say.
> They are completely nonsense to non-programmers, and they rarely ever have good documentation
This applies the same to other "popular" languages like Javascript i.e. NodeJs. I'd argue Java apps being supported by large corporations actually have better documentation.
> Most only show up in old SO post, or application specific forums
And a lot of "popular" issues only show up in a hidden github issues comment that may or may not be relevant anymore.
Everything you've described all happens in many other languages today. Python is personally one of my more prominent nemeses, as the ML bubble marches forward; I can't even tell you how many venvs I've got with various binaries for Nvidia interfaces along for the ride. The .NET family still has that terrible library installer for older solutions that lingers like a bad odor.
And let's not forget the joy that is Python's many, many esoteric values due to rampant signature changes in dependency hell. Whoops! That library that just got accidentally updated renamed a critical function 2 layers deep in the 70+ transitive dependency hierarchy, and threw an error; too bad it didn't manifest before you spent 10 hours of processing time.
.NET is not a subject to the insanity that is managing host-installed dependencies in and versions of Python.
For SDKs themselves, they are installed in a canonical path, and only a single (latest) executable exists in path, called "muxer", also working as front-end for all commands. It then can choose corresponding SDK and runtime dependencies installed in subfolders depending on a situation. You can easily do sudo apt install dotnet-sdk-8/7/6.0 in any order and it will "just work".
It also seems you are forgetting just how bad early Java was, from a programming and user standpoint. Java errors like NullPointerException became a meme because they were so prevalent in user space, and required so much energy and time to get things working. As a result, people typically refused to update any part of Java once their app was working, to avoid breaking things. And that was _if_ the install was registered with a package manager or Windows Update so updates could be reported.