>>21
I didn't suggest getting rid of reference equality, I suggested replacing it with the magic instance variable.
Your "magic instance variable" idea does not work. The reason is because even though String is immutable, you can have any number of different String objects with the same content if they are created in different ways (e.g. literal Strings from the static string table vs. runtime-generated strings). So now you still need a full string check when the magic check fails (which will be virtually all of the time), only now you need a way of uniquely generating these magic checks.
All you've really given us is the address check optimization for operator==. Big deal.
Great. So now programmers are forced to write comprehensive .equals() methods (or, god forbid, .hashCode()) just to be able to determine whether two differing mutable objects are the same objects, and they have no way of knowing whether two identical ones are different at all?
What the fuck part of my post gave you that idea? == should be disabled for IMMUTABLE TYPES, because the comparison is undefined. It is literally not in the language specification how a Java VM should behave when using == to compare string objects with other string objects and with string literals; it's just an object comparison, and the VM is allowed to do whatever optimizations it wants with regard to String instances. It should be disabled for this very reason; it is not defined.
You of course need both comparisons for mutable objects. The result IS defined for these, and so reference comparison should obviously be allowed. Reading comprehension FTW.
The way to fix the language is to not have primitive types at all, like Smalltalk. Unfortunately Java wanted this "half way" idea between C++ and a proper fully object-oriented syntax in order to get good performance. We all know how well that turned out.