Just because something is a well known-flaw doesn't make it a glaring flaw.

There's a reason newer JVM languages like Kotlin use == as an alias for equals instead of reference equality.

What if you are interested in reference equality?

In practice, how often are you interested in it? C# has `Object.referenceEquals()` because you _may_ want this sometimes. But to have reference equality be the default for something like `==` is a design flaw. Not one that can be fixed now, of course, but it will continue to cause bugs for years to come.

Sometimes, it happens in core Java libraries themselves: https://bugs.openjdk.java.net/browse/JDK-8274779

https://github.com/openjdk/jdk/blob/722d639fad2e4fc6eb2aabd4...

Dunno, I do a fair bit of low level java work, happens every once in a while.

Curiously, I don't do a lot of value-comparisons. Based on grepping in the repo for my search engine, I appear to do one every 1000 lines of code. May just be how I write code though. Some people seem to do that a lot more.

Python uses the `is` operator, which is semantically much more explicit (and arguably correct, though C#'s use of the `is` operator is probably more correct).

edit:

Kotlin uses `===`, which is another good option.

=== seems almost more dangerous. It's a lot easier to tell == from Objects.equals(a,b) than == from ===.

Seriously?

Yes.

Look, languages are moving away from permitting constructs like "if (x = 1)" because it's difficult to distinguish from "if (x == 1)". Adding "if (x === 1)" into the mix is arguably a step backwards in terms of clarity.

This is like saying that null references are a non-issue because it have been there since the 1970s and that "true" $LANGUAGE developers never collide head-first into invalid dereferences. If something is ridiculous and un-ergonomic, it stays ridiculous and un-ergonomic no matter what. Reference comparison by default is ridiculous and un-ergonomic.

Null references exist in every language with the concept of null. It has nothing to do with Java specifically, and Java gives you a lot of information to debug them.

That's right, but that also doesn't answer the parent's point to which I fully agree.