Is there a possibility of the string equality operator (==) being fixed?

[Brian Goetz]

First of all, the question is framed in a way that assumes its own 
conclusion; that somehow there is something "broken" to be "fixed". The 
== operator on object references asks a simple, well-defined, 
fundamental question: do these two object references _refer to the same 
object_.  There is a similar, related question of "do these two objects 
_encode the same domain value_" (which is inherently class-specific), 
and that goes by the name of the "equals" method. These are two 
different questions, and it is important to be able to ask each.  One 
does not replace the other.

The presumption that something is "broken" comes from the subjective 
perception that the "less important" operation got the "better" name.  
Indeed, without a clear understanding of what these two questions are, 
it is easy to make mistakes.  The comparison to C# illustrates that 
other languages could make other choices, which might result in a 
different category of mistakes that users might or might not make.

While the answer you got said "backward compatibility", this is a 
too-simplistic (though often repeated) answer; the answer really is 
"because this exactly is how the language was designed to work", which 
means this is not something to be "fixed".  If we agreed that this 
original intention was wrong-headed, then the issue of compatibility 
would come in -- that there are billions of lines of code that have been 
written in Java, and turning Java into Java++, whether "better" or not, 
would break many of them.  (Sometimes language do make incompatible 
changes because something is so egregiously broken that it is better to 
break half the world's code than continue living with it, but the bar 
for this is extremely high, and "I wish the other operation got the good 
name" doesn't come near it.)

But the eye-rolling of "how much are we going to sacrifice at the altar 
of backward compatibility" is misplaced.  The == operator on object 
references still has a clearly defined meaning, and it is the intended 
meaning.  It may be unfortunate that the "good" name was taken by the 
"less common" operation, but programming languages are full of such 
things, and one can easily identify such things in each of the other 19 
languages you list.  Ultimately, when there are two ways to do something 
(such as identity comparison and state comparison), someone has to 
choose which one gets which name, and sometimes someone doesn't agree 
with that choice.

In the future, when Project Valhalla delivers value types, which are 
classes whose instances have no object identity, the == operator will 
compare these objects by their state, not their identity (since they 
have none.)  But even this would not obviate the need for 
Object::equals, since there are many classes that are suitable to be 
value types (such as Rational) where multiple distinct representations 
(e.g., 1/2 and 2/4) are mathematically equal.  So even there, we need 
different ways to spell "same object" and "equivalent value".

In the farther future, if Java ever has operator overloading, one might 
be able to overload `==`, but being able to do that brings its own set 
of problems and confusions.

Which is to say, there really are two questions here, "same object" and 
"domain equivalence", and you need ways to ask both.




On 10/22/2023 3:29 PM, David Alayachew wrote:
> Hello,
>
> Thank you for reaching out!
>
> I'm pretty sure that the amber-dev mailing list is not the correct 
> place for this type of question. This topic usually goes on at the 
> following mailing list instead. I've CC'd it for you. I would also 
> encourage you to remove amber-dev from your CC when responding to me, 
> or anyone else on this thread.
>
> discuss at openjdk.org
>
> To answer your question, this is a very common request, and the 
> biggest answer is definitely still the backwards compatibility 
> problem. But tbh, the question I have for you is this -- is it such a 
> big cost to call the o1.equals(o2) method instead of using ==? And if 
> you want to handle nulls too, you can import java.util.Objects (that 
> class is full of useful static utility methods) and then just say 
> Objects.equals(o1, o2) instead. I am pretty sure that that exact 
> method was created in response to your exact question.
>
> I understand it might be inconvenient, but making a change like you 
> suggested would be very disruptive for very little benefit. All you 
> would gain from doing this would be a slightly better syntax for 
> representing object equality and a little more ease when it comes to 
> teaching somebody Java. Is that really worth the effort?
>
> As for the class-file api, I'll CC them so that someone can fact check 
> me. Assuming I'm not wrong (no one responds to that point 
> specifically), I would also drop that mailing list from your CC when 
> responding.
>
> The purpose of the Class-File API was to build and transform class 
> files. So that seems unrelated to what you want. You want to repurpose 
> old syntax, but syntax stops being relevant after compilation, and it 
> is these compiled class files that the Class-File API deals in. If we 
> tried to use that API to handle class files created with the old 
> syntax, then we would have a migration and clarity problem, amongst 
> much more.
>
> Let us know if you have any more questions.
>
> Thank you for your time!
> David Alayachew
>
>
> On Sun, Oct 22, 2023 at 2:12 PM tzengshinfu <tzengshinfu at gmail.com> wrote:
>
>     Hi, folks:
>
>     When I switched my primary programming language from C# to Java, I
>     found myself perplexed by 'string comparison' (and still do at
>     times). While string comparisons can sometimes become quite
>     intricate, involving issues like case sensitivity, cultural
>     nuances... most of the time, all that's needed is string1 == string2.
>
>     I discovered that a similar question was asked a decade ago
>     (https://www.reddit.com/r/java/comments/1gjwpu/will_the_equals_operator_ever_be_fixed_with/),
>     with responses indicating that it's due to 'Backward
>     compatibility,' and therefore, unlikely to change. (Backward
>     compatibility! We just keep piling new things on top of historical
>     baggage, and for users coming from school or from other languages
>     like C#, Python, C++, Rust, Golang, Kotlin, Scala, JavaScript,
>     PHP, Rlang, Swift, Ruby, Dart... the top 20 languages according to
>     PYPL, having to consult the so-called 'Java FAQ' can be frustrating.
>
>     But I believe that if something is amiss, it should be corrected
>     to keep moving forward. It would be fantastic if this issue could
>     be addressed in a new version of Java and an automatic conversion
>     feature provided to fix places in user code that use
>     String.equals. (Similar to the JVM's preview feature switch) Is
>     the Class-File API a potential solution to this problem? Is my
>     idea unrealistic?
>
>     /* GET BETTER EVERY DAY */
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/discuss/attachments/20231022/02e1253e/attachment-0001.htm>