<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">I think this whole discussions
        illustrates a deeper point about language design, and how
        simple-seeming "fixes" turn out to be complicated.  <br>
        <br>
        Tzengshifu arrived at these thoughts by coming from another
        language with an existing codebase, and finding that users
        stumble when things are "mostly the same but a little
        different."  From there, it is easy to leap to "so, something
        must be broken", and from there, easier still to leap to
        "solutions".  <br>
        <br>
        But the reality is that languages are (hopefully) organic
        wholes; even when one language adopts a feature "inspired by" a
        feature in another language, it is more like an organ transplant
        than buying a new shirt, because invariably each language
        feature connects to many other features.  In order for a
        transplant to be successful, all the vessels have to be
        carefully reconnected (to the right things.)<br>
        <br>
        The story of autoboxing is a cautionary tale; one the one hand,
        it is convenient most of the time, but the mismatch between
        "primitives compare by value, objects compare by reference"
        bites us when we try to blur this distinction.  This is another
        flavor of the "C# equality depends on static types"; it's a
        visible seam in the carpet that most of the time we can safely
        navigate, but every once in a while we trip over.<br>
        <br>
        <br>
      </font></font><br>
    <div class="moz-cite-prefix">On 10/31/2023 11:21 AM, Anatoly
      Kupriyanov wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAGwStpCQ4p15UEOOeNS=w9V557JDmr_TO2+AcW+hpn37kvzNNQ@mail.gmail.com">
      
      <div dir="ltr">
        <div>I believe the thing you are asking for is contradicting the
          Java language design philosophy. Java is a very simple
          language, relatively low-level, like a Pure C - everything
          means quite literally, no hidden stuff. The == is a
          language-level and means a very simple thing.</div>
        <div><br>
        </div>
        <div>In other languages like C++ and C# the == could also be a
          user-defined operator (a method with a special syntax) and
          could do unexpected things. Hence that quirky behaviour with
          the object comparison as demonstrated in the Jens email.</div>
        <div><br>
        </div>
        <div>There are few compromises which allow to make code more
          readable, like auto-boxing. Even this simple thing is
          introducing a havoc so you have got confused why "1 == 1" but
          "200 != 200" for the Integer type.</div>
        <div>Hence it is a good thing to keep the design as simple as
          possible (but not simpler!).</div>
        <div><br>
        </div>
        <div>If you don't like explicit (unfortunately more verbose as a
          consequence) syntax of Java like Objects.equals(str1, str2),
          and you are after cooler languages with more features you
          could look into other JVM-languages like Scala or Kotlin which
          do == and other things differently.<br>
        </div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Tue, 31 Oct 2023 at 02:11,
          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">Thank you, Anatoly, for informing me about
              `IntegerCache`.<br>
              As a developer experienced in C# and
              JavaScript/TypeScript, I am currently responsible for
              migrating our in-house systems from C# to Java.<br>
              I also have the responsibility of training and sharing
              knowledge with others.<br>
              <br>
              I was surprised by the following result in Java:<br>
              <br>
              ```java<br>
              Integer int1 = 100;<br>
              Integer int2 = 100;<br>
              Integer int3 = int1 + 100;<br>
              Integer int4 = int2 + 100;<br>
              out.println(int3 == int4); // false<br>
              ```<br>
              <br>
              This is different from how it works in C#:<br>
              <br>
              ```C#<br>
              Int32 int1 = 100;<br>
              Int32 int2 = 100;<br>
              Int32 int3 = int1 + 100;<br>
              Int32 int4 = int2 + 100;<br>
              Console.Write(int3 == int4); // True<br>
              ```<br>
              <br>
              Now, I understand that Java's design philosophy (thanks to
              Brian for patiently explaining) leads to this behavior.<br>
              I will make an effort to understand how this works under
              the hood and include it in my Java FAQ documentation.<br>
              My initial thoughts and suggestions were aimed at
              colleagues who are also transitioning from other
              programming languages and newcomers to Java who bring
              their language experiences.<br>
              Naturally, they might find the unexpected results in
              certain use cases, and I hope to find ways to make this
              learning curve smoother without disrupting the existing
              framework.<br>
              <br>
              Without breaking the current architecture, both Solution A
              (changing String1 == String2 to String::equals()) and
              Solution B (introducing a new string/str class to replace
              the String class) are unfeasible (thanks to Nathan for
              preventing "I think it's rarely used, but in reality, it's
              not, and everything breaks").<br>
              <br>
              Can I propose a Solution C?<br>
              <br>
              Solution C: Introduce the === and !== operators for value
              comparison (equivalent to Object::equals()).<br>
              <br>
              For example:<br>
              <br>
              ```java<br>
              if (Integer4 === Integer1 + Integer2 + Integer3) {<br>
                  // Do something...<br>
              }<br>
              ```<br>
              <br>
              Would be equivalent to:<br>
              <br>
              ```java<br>
              if (Integer4.equals(Integer1 + Integer2 + Integer3)) {<br>
                  // Do something...<br>
              }<br>
              ```<br>
              <br>
              From a visual perspective, I believe that the === and !==
              operators can reduce the chances of typos and make the
              code look cleaner, with fewer parentheses compared to
              using equals().<br>
              Sometimes, symbols can convey meaning more clearly than
              text. This idea stems from my experience with Delphi,
              where the use of keywords like begin and end mixed with
              variable declarations and expressions made code difficult
              to read in a plain text editor, despite IDE features like
              highlighting and automatic formatting. Java's use of {}
              solved this issue.<br>
              However, there are also counterexamples, such as Rust's
              code, where excessive symbols may contribute to a steep
              learning curve.<br clear="all">
              <div>
                <div dir="ltr" class="gmail_signature"><br>
                  /* GET BETTER EVERY DAY */<br>
                  <br>
                  <br>
                </div>
              </div>
            </div>
          </div>
        </blockquote>
      </div>
      <br clear="all">
      <br>
      <span class="gmail_signature_prefix">-- </span><br>
      <div dir="ltr" class="gmail_signature">WBR, Anatoly.</div>
    </blockquote>
    <br>
  </body>
</html>