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

[Jens Lideström]

Remember that C# has its own quirks regarding the behaviour of ==.

Example of the behaviour in C#:

```
string s1 = new String("1");
string s2 = new String("1");
object o1 = s1;
object o2 = s2;
Console.WriteLine(s1 == s2); // True, overload for string kicks in
Console.WriteLine(o1 == o2); // False, reference equality!

int? i1 = 1;
int? i2 = 1;
object o1 = i1;
object o2 = i2;
Console.WriteLine(i1 == i2); // True, overload for Nullable<int> kicks 
in
Console.WriteLine(o1 == o2); // False, reference equality!
```

That is, in C# the behaviour of == varies for the same objects, 
depending on what types the references have.

Both approaches have their advantages and disadvantages. But to me 
Java's approach seems more sensible: For reference types == always means 
reference equality.

Best regards,
Jens Lideström

On 2023-10-31 03:10, tzengshinfu 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 */