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

[Brian Goetz]

I think this whole discussions illustrates a deeper point about language 
design, and how simple-seeming "fixes" turn out to be complicated.

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".

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.)

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.



On 10/31/2023 11:21 AM, Anatoly Kupriyanov wrote:
> 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.
>
> 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.
>
> 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.
> Hence it is a good thing to keep the design as simple as possible (but 
> not simpler!).
>
> 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.
>
>
> On Tue, 31 Oct 2023 at 02:11, tzengshinfu <tzengshinfu at gmail.com> wrote:
>
>     Thank you, Anatoly, for informing me about `IntegerCache`.
>     As a developer experienced in C# and JavaScript/TypeScript, I am
>     currently responsible for migrating our in-house systems from C#
>     to Java.
>     I also have the responsibility of training and sharing knowledge
>     with others.
>
>     I was surprised by the following result in Java:
>
>     ```java
>     Integer int1 = 100;
>     Integer int2 = 100;
>     Integer int3 = int1 + 100;
>     Integer int4 = int2 + 100;
>     out.println(int3 == int4); // false
>     ```
>
>     This is different from how it works in C#:
>
>     ```C#
>     Int32 int1 = 100;
>     Int32 int2 = 100;
>     Int32 int3 = int1 + 100;
>     Int32 int4 = int2 + 100;
>     Console.Write(int3 == int4); // True
>     ```
>
>     Now, I understand that Java's design philosophy (thanks to Brian
>     for patiently explaining) leads to this behavior.
>     I will make an effort to understand how this works under the hood
>     and include it in my Java FAQ documentation.
>     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.
>     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.
>
>     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").
>
>     Can I propose a Solution C?
>
>     Solution C: Introduce the === and !== operators for value
>     comparison (equivalent to Object::equals()).
>
>     For example:
>
>     ```java
>     if (Integer4 === Integer1 + Integer2 + Integer3) {
>         // Do something...
>     }
>     ```
>
>     Would be equivalent to:
>
>     ```java
>     if (Integer4.equals(Integer1 + Integer2 + Integer3)) {
>         // Do something...
>     }
>     ```
>
>     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().
>     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.
>     However, there are also counterexamples, such as Rust's code,
>     where excessive symbols may contribute to a steep learning curve.
>
>     /* GET BETTER EVERY DAY */
>
>
>
>
> -- 
> WBR, Anatoly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231031/de5e0203/attachment-0001.htm>