Is there a possibility of the string equality operator (==) being fixed?
John Hendrikx
hjohn at xs4all.nl
Tue Oct 31 13:42:18 UTC 2023
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>
More information about the amber-dev
mailing list