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

[tzengshinfu]

Hello, folks!

Have a great weekend! I've been busy migrating our system from C# to the
Java ecosystem (we also switched our system's host OS from Windows Server
to Linux), so my responses are a bit delayed.

Thanks to Jens & Pedro for sharing. I noticed that in C#, there is an
attempt to make the comparison behavior of String class/Nullable class
values similar to built-in value types.
PS: For address comparison, the static method object::ReferenceEquals is
used.

Let me modify the previous C# example:
```csharp
string s1 = new string(new char[] { '1' });
string s2 = new string(new char[] { '1' });
object o1 = s1;
object o2 = s1;

Console.WriteLine(s1 == s2); // True, same value
Console.WriteLine(object.ReferenceEquals(o1, o2)); // True, same reference
```

This is equivalent to the following Java example:
```java
String s1 = new String("1");
String s2 = new String("1");
Object o1 = s1;
Object o2 = s1;

System.out.println(s1.equals(s2)); // true, same value
System.out.println(o1 == o2); // true, same reference
```

Now that I know more, understand the history, and gradually grasp the
design philosophy of Java (Thank you, Brian), I realize there are two
worlds. Initially entering Java, I wasn't aware of these two worlds; I just
wondered why I could use == for value comparison in the world of primitive
data types, but for string comparison, I had to use String::equals.
At that time, I just wished that the commonly used String class could be
compared by value like primitive data types.
C#, as a later entrant with a smaller ecosystem impact, could make
adjustments to bridge the gap between these two worlds.
However, Java, being the pioneer, would face too high a cost to make such
changes.

I now understand that Java tends to be detailed, revealing as many details
as possible.
Object value comparison is not simple; a class can have multiple fields,
and fields can be other classes. When comparing two classes' values, you
can compare all fields or just a few. Additionally, Java does not support
operator overloading. Overriding Object::equals to perform value comparison
is reasonable.
I still look forward to the arrival of the era of value types mentioned by
Brian, where we can use a single method for value comparison in most cases.

Thank you for your insights, John. Currently, in the Web API parameters, I
use Integer to represent nullable (similar to C#'s int?), and it works well.

Lastly, let me mention a feature of C#: syntactic sugar. Honestly, after
coming to the Java world, I've given up on sugar (except for var
declarations). After several developments in C#, I find it challenging to
understand the current version.
Syntactic sugar, such as extension methods and operator overloading, can be
interchangeable with the original syntax. While it reduces visual burden,
it hides many details, making it a cognitive burden for beginners.
However, I must admit that syntactic sugar has its advantages in terms of
code input.
I plan to research how to develop an IDE plugin (I use VSCode) in my free
time. This plugin will have two purposes:
1. In the input method, it will act like a shortcut, converting specific
operators into syntactic transformations.
2. It will appropriately display syntactic sugar information next to the
original code (I don't want to make any changes to the original code; the
original code should display the most detailed details because it is the
common language for everyone).

Taking the previously proposed solution C as an example:
```java
String s1 = "1";
String s2 = "1";
s1 === // After entering ===, it will automatically be converted to the
following format
s1.equals(
``````
Another use case:
```java
BigDecimal d1 = new BigDecimal("1");
BigDecimal d2 = new BigDecimal("2");
BigDecimal d3 = new BigDecimal("0");
d3 = d1 + // After entering +, it will automatically be converted to the
following format
d3 = d1.add(
```

Or maybe there is already such a plugin? That would be great!


/* GET BETTER EVERY DAY */
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231111/a502eb0f/attachment.htm>