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

[John Hendrikx]

I think this comparison is not very valid.

`Integer` is not the type you an experienced Java developer would use 
for this, you'd use `int` which can't be set to `null`, just like 
`Int32` in C# can't be set to `null`.  Generally, use of `Integer` like 
you do in your example is not recommended and often a sign that the 
developer is not yet that familiar with Java.  The only places I'd 
expect to see `Integer` is in generic declarations (like List<Integer>) 
or at the input/output layers of your application to indicate a value 
can be an integer OR null.  Usage like this would immediately (and 
safely) be replaced with `int` (doing calculations on them means they 
can't be null so `int` is the correct type to use).

```java
int int1 = 100;
int int2 = 100;
int int3 = int1 + 100;
int int4 = int2 + 100;
out.println(int3 == int4); // true!
```

--John

------ Original Message ------
>From "tzengshinfu" <tzengshinfu at gmail.com>
To amber-dev at openjdk.org
Date 31/10/2023 03:10:16
Subject Re: Is there a possibility of the string equality operator (==) 
being fixed?

>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 */
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231031/c0c64b84/attachment-0001.htm>