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

Brian Goetz brian.goetz at oracle.com
Tue Oct 31 14:05:36 UTC 2023


>
> Can I propose a Solution C?
>
> Solution C: Introduce the === and !== operators for value comparison 
> (equivalent to Object::equals()).

As will not be surprising, this is not a new suggestion either.

JavaScript had good success with ===, but they started out in a very 
different position; == was so catastrophically difficult to reason about 
that it was reasonable to tell users to basically forget about ==.  
Moving to === was virtually a forced move for them.  We don't have that 
problem; == has a firm, and learnable foundation in Java. But, it gets 
worse.

Inventing === as a synonym for == is purely a syntactic hack; there are 
no useful new semantics here.  And because both == and === will be valid 
on all types, people will still make mistakes that are going to be hard 
to catch -- arguably harder, because they look so much alike.

But here's the killer for this idea; .equals() is asymmetric; calling 
a.equals(b) can invoke different code than b.equals(a), if they have 
different implementation classes and both refine equals().  Which means 
`===` is not commutative, and which you put on the left matters.  But 
this is not how we expect equality comparison operators to work.




More information about the amber-dev mailing list