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

[Archie Cobbs]

On Thu, Oct 26, 2023 at 5:21 AM tzengshinfu <tzengshinfu at gmail.com> wrote:

> I've noticed that `string comparison` in Java can be confusing ...
>

This idea strikes me as misguided.

What you're saying does make sense - IF you are looking at Java from the
perspective of another programming language where strings have a special,
unique type defined in the language itself. For example, Javascript, which
has "boolean", "number", "string", "object", etc.

But for this discussion, try to break out of that mindset.

What you're missing is that Java was designed based on different design
principles. Let's go back in history for a moment...

The design of Java was in part an anti-complexity reaction to the overly
complex design of C++. And Java became wildly successful as a result.

This is totally analogous to how Unix was an anti-complexity reaction to
the overly complex design of Multics. And Unix became wildly successful as
a result.

In Java, you have 8 primitive types and Object. That's it! Everything that
can contain state is one of those types. If you can understand 9 things,
you can understand everything.

In Unix all system resources are expressed as files, including block
devices, serial ports, etc. If you know how to open and read a file, you
know how to work with all of those system resources. One and done!

In Javascript, if you want a string, you use the "string" type of the
language. In Java, you use the class "java.lang.String" which is a normal
class just like any other.

In Javascript, if you want a map, you use the "object" type of the
language. In Java, you use "java.util.HashMap", or "java.util.TreeMap", or
whatever. Again, these are normal classes just like any other.

So to change how String behaves would be to introduce a 10th "thing" into
the language... No thanks!!

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231026/33c01b27/attachment.htm>