<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    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.  <br>
    <br>
    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.  <br>
    <br>
    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.)  <br>
    <br>
    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.  <br>
    <br>
    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".  <br>
    <br>
    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.  <br>
    <br>
    Which is to say, there really are two questions here, "same object"
    and "domain equivalence", and you need ways to ask both.  <br>
    <br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 10/22/2023 3:29 PM, David Alayachew
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAA9v-_P+VzrqRYuc2QR=jAuSzn2nDRQX3R3StEVrt46mmW=1Pg@mail.gmail.com">
      
      <div dir="ltr">
        <div class="gmail_default" style="font-family:monospace">Hello,</div>
        <div class="gmail_default" style="font-family:monospace"><br>
        </div>
        <div class="gmail_default" style="font-family:monospace">Thank
          you for reaching out!<br>
        </div>
        <div class="gmail_default" style="font-family:monospace"><br>
        </div>
        <div class="gmail_default" style="font-family:monospace">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.<br>
        </div>
        <div class="gmail_default" style="font-family:monospace"><br>
        </div>
        <div class="gmail_default" style="font-family:monospace"><a href="mailto:discuss@openjdk.org" moz-do-not-send="true" class="moz-txt-link-freetext">discuss@openjdk.org</a></div>
        <div class="gmail_default" style="font-family:monospace"><br>
        </div>
        <div class="gmail_default" style="font-family:monospace">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.<br>
        </div>
        <div><br>
        </div>
        <div>
          <div style="font-family:monospace" class="gmail_default">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?</div>
        </div>
        <div><br>
        </div>
        <div>
          <div style="font-family:monospace" class="gmail_default">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.</div>
          <div style="font-family:monospace" class="gmail_default"><br>
          </div>
          <div style="font-family:monospace" class="gmail_default">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.<br>
          </div>
        </div>
        <div><br>
        </div>
        <div>
          <div style="font-family:monospace" class="gmail_default">Let
            us know if you have any more questions.<br>
          </div>
        </div>
        <div><br>
        </div>
        <div>
          <div style="font-family:monospace" class="gmail_default">Thank
            you for your time!</div>
          <div style="font-family:monospace" class="gmail_default">David
            Alayachew<br>
          </div>
          <br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Sun, Oct 22, 2023 at
          2:12 PM tzengshinfu <<a href="mailto:tzengshinfu@gmail.com" moz-do-not-send="true" class="moz-txt-link-freetext">tzengshinfu@gmail.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div dir="ltr">
            <div dir="ltr">
              <p style="border:0px solid
                rgb(217,217,227);box-sizing:border-box;margin:0px 0px
1.25em;color:rgb(55,65,81);font-family:Söhne,ui-sans-serif,system-ui,-apple-system,"Segoe
                UI",Roboto,Ubuntu,Cantarell,"Noto
                Sans",sans-serif,"Helvetica
                Neue",Arial,"Apple Color
                Emoji","Segoe UI Emoji","Segoe UI
                Symbol","Noto Color
                Emoji";font-size:16px;background-color:rgb(247,247,248)">Hi,
                folks:<br>
              </p>
              <p style="border:0px solid
                rgb(217,217,227);box-sizing:border-box;margin:1.25em
0px;color:rgb(55,65,81);font-family:Söhne,ui-sans-serif,system-ui,-apple-system,"Segoe
                UI",Roboto,Ubuntu,Cantarell,"Noto
                Sans",sans-serif,"Helvetica
                Neue",Arial,"Apple Color
                Emoji","Segoe UI Emoji","Segoe UI
                Symbol","Noto Color
                Emoji";font-size:16px;background-color:rgb(247,247,248)">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.</p>
              <p style="border:0px solid
                rgb(217,217,227);box-sizing:border-box;margin:1.25em
0px;color:rgb(55,65,81);font-family:Söhne,ui-sans-serif,system-ui,-apple-system,"Segoe
                UI",Roboto,Ubuntu,Cantarell,"Noto
                Sans",sans-serif,"Helvetica
                Neue",Arial,"Apple Color
                Emoji","Segoe UI Emoji","Segoe UI
                Symbol","Noto Color
                Emoji";font-size:16px;background-color:rgb(247,247,248)">I
                discovered that a similar question was asked a decade
                ago (<a href="https://www.reddit.com/r/java/comments/1gjwpu/will_the_equals_operator_ever_be_fixed_with/" style="border:0px solid
                  rgb(217,217,227);box-sizing:border-box;text-decoration-line:none" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.reddit.com/r/java/comments/1gjwpu/will_the_equals_operator_ever_be_fixed_with/</a>),
                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.</p>
              <p style="border:0px solid
                rgb(217,217,227);box-sizing:border-box;margin:1.25em 0px
0px;color:rgb(55,65,81);font-family:Söhne,ui-sans-serif,system-ui,-apple-system,"Segoe
                UI",Roboto,Ubuntu,Cantarell,"Noto
                Sans",sans-serif,"Helvetica
                Neue",Arial,"Apple Color
                Emoji","Segoe UI Emoji","Segoe UI
                Symbol","Noto Color
                Emoji";font-size:16px;background-color:rgb(247,247,248)">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?</p>
              <p style="border:0px solid
                rgb(217,217,227);box-sizing:border-box;margin:0px 0px
1.25em;color:rgb(55,65,81);font-family:Söhne,ui-sans-serif,system-ui,-apple-system,"Segoe
                UI",Roboto,Ubuntu,Cantarell,"Noto
                Sans",sans-serif,"Helvetica
                Neue",Arial,"Apple Color
                Emoji","Segoe UI Emoji","Segoe UI
                Symbol","Noto Color
                Emoji";font-size:16px;background-color:rgb(247,247,248)">
              </p>
              <div>
                <div dir="ltr" class="gmail_signature">/* GET BETTER
                  EVERY DAY */<br>
                </div>
              </div>
            </div>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>