Wouldn't it be nice if Java could fix == ?

[Douglas Pearson doug-list-S/[e-mail] [seajug]]

Is it fair to say that virtually all Java developers feel that the behavior
of == in Java is a mistake? That it should in fact call the .equals()
method on an object instead of doing instance equality?

If so - is there any process where this could actually get changed in the
language?

I'd propose:
== calls .equals() if the LHS is an object
=== (a new operator) would do instance equality - if you really really
want it

Sure, a change like this would theoretically not be backwards compatible.
You could be relying on == to not do the more general equals test. But
it's hard to imagine this is a common practice and the fix would be trivial
(move to the === operator).

Seems to me this causes more than it's share of Java bugs - switching
between "Integer" and "int" for a definition usually produces almost no
changes (thanks to boxing) except the semantics of == silently changes

Oh well... I can dream right?

Doug

[Konstantin Ignatyev [e-mail] [seajug]]

Just use Scala and your wish is granted :)

Post by Douglas Pearson doug-list-S/***@public.gmane.org [seajug]
Is it fair to say that virtually all Java developers feel that the
behavior of == in Java is a mistake? That it should in fact call the
.equals() method on an object instead of doing instance equality?
If so - is there any process where this could actually get changed in the
language?
== calls .equals() if the LHS is an object
=== (a new operator) would do instance equality - if you really really
want it
Sure, a change like this would theoretically not be backwards compatible.
You could be relying on == to not do the more general equals test. But
it's hard to imagine this is a common practice and the fix would be trivial
(move to the === operator).
Seems to me this causes more than it's share of Java bugs - switching
between "Integer" and "int" for a definition usually produces almost no
changes (thanks to boxing) except the semantics of == silently changes
Oh well... I can dream right?
Doug

--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[George Smith [e-mail] [seajug]]

In general I am not a fan of suggestions to switch languages as a response
to a suggestion to improve a language, in this case, given Java's (Sun's
and now Oracle's) insistence on backward compatibility I doubt that such a
change could occur.

However, having said that, the "insistence on backward compatibility" is
primarily about class files, and has not kept them from Source Code
already, two examples:
JDBC interface (long history of not versioning w/ new methods)!
Objects.class and import *.

It is critical however for the compiler to actually fail when these changes
are encountered. Doug's proposed change does not meet this criteria.

An alternative, I first heard from Jason Osgood, is the concept of "Light
Weight Objects" (I think that is he called them) that would allow you to
"efficiently" pretend that primitives are objects, thus letting us use
.equals() w/ primitives. Of course with all the new syntactic sugar begin
introduced these days in to Java the compiler could simply call the
appropriate static method when the LHS was a primitive (this of course
would be in-lined by the JIT).

George

Post by Konstantin Ignatyev kgignatyev-***@public.gmane.org [seajug]
Just use Scala and your wish is granted :)

Post by Douglas Pearson doug-list-S/***@public.gmane.org [seajug]
Is it fair to say that virtually all Java developers feel that the
behavior of == in Java is a mistake? That it should in fact call the
.equals() method on an object instead of doing instance equality?
If so - is there any process where this could actually get changed in the
language?
== calls .equals() if the LHS is an object
=== (a new operator) would do instance equality - if you really really
want it
Sure, a change like this would theoretically not be backwards compatible.
You could be relying on == to not do the more general equals test. But
it's hard to imagine this is a common practice and the fix would be trivial
(move to the === operator).
Seems to me this causes more than it's share of Java bugs - switching
between "Integer" and "int" for a definition usually produces almost no
changes (thanks to boxing) except the semantics of == silently changes
Oh well... I can dream right?
Doug

--
Konstantin Ignatyev
PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Scott Shipp [e-mail] [seajug]]

I don't think that backwards-compatibility would be only a theoretical problem or trivial. Think about how many equals() methods are out there with a == check for speed? If they changed it now all those methods have to be rewritten or else they become endlessly recursive. Second, what would "o == null" mean? o.equals(null), I guess? Which also throws us into the same problem with a recursive call since many equals methods have a (if o == null) return false type of line in them. So we'd be going through our equals() methods to replace "==" with "===" I guess. Seems non-trivial to me. YMMV.
Scott

On Tue, Jul 8, 2014 at 10:11 PM, Konstantin Ignatyev kgignatyev-***@public.gmane.org [seajug] <seajug-***@public.gmane.org> wrote:



























Just use Scala and your wish is granted :)

On Tue, Jul 8, 2014 at 5:51 PM, Douglas Pearson doug-list-S/***@public.gmane.org [seajug] <seajug-***@public.gmane.org> wrote:




























Is it fair to say that virtually all Java developers feel that the behavior of == in Java is a mistake? That it should in fact call the .equals() method on an object instead of doing instance equality?



If so - is there any process where this could actually get changed in the language?
I'd propose: == calls .equals() if the LHS is an object === (a new operator) would do instance equality - if you really really want it



Sure, a change like this would theoretically not be backwards compatible. You could be relying on == to not do the more general equals test. But it's hard to imagine this is a common practice and the fix would be trivial (move to the === operator).



Seems to me this causes more than it's share of Java bugs - switching between "Integer" and "int" for a definition usually produces almost no changes (thanks to boxing) except the semantics of == silently changes



Oh well... I can dream right?
Doug
--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000



Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)

[Steve Lewis [e-mail] [seajug]]

It strikes me that the biggest issue with == probably comes from the
requirement to use .equals for String text equality. String already
overloads + and += so overloading == for String is not a huge stretch. In
addition == for Strings is used extremely rarely so one might expect
relatively little code to break if the == operator was overloaded.
<https://groups.yahoo.com/neo/groups/seajug/conversations/topics/20785;_ylc=X3oDMTJyZ3NjYWxvBF9TAzk3MzU5NzE1BGdycElkAzIyNjczNDIEZ3Jwc3BJZAMxNzA1MDA2OTA1BG1zZ0lkAzIwNzg1BHNlYwNkbXNnBHNsawN2bXNnBHN0aW1lAzE0MDU3NTYyMzk->
Since String has long been a final class the change is easy and
subclasses are not an issue.
Yes there may be reasons to set == to mean .equals in other cases but as
others have pointed out these other cases can cause a lot of existing code
to break whereas a change to String should not.

[George Smith [e-mail] [seajug]]

Good observation Steve!

When I am writing libraries, that have overloaded methods to handle the
"primitives" I often lump String into the "primitive" group because its use
so often is more similar to an 'int' than say a Date.

George

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
It strikes me that the biggest issue with == probably comes from the
requirement to use .equals for String text equality. String already
overloads + and += so overloading == for String is not a huge stretch. In
addition == for Strings is used extremely rarely so one might expect
relatively little code to break if the == operator was overloaded.
<https://groups.yahoo.com/neo/groups/seajug/conversations/topics/20785;_ylc=X3oDMTJyZ3NjYWxvBF9TAzk3MzU5NzE1BGdycElkAzIyNjczNDIEZ3Jwc3BJZAMxNzA1MDA2OTA1BG1zZ0lkAzIwNzg1BHNlYwNkbXNnBHNsawN2bXNnBHN0aW1lAzE0MDU3NTYyMzk->
Since String has long been a final class the change is easy and
subclasses are not an issue.
Yes there may be reasons to set == to mean .equals in other cases but
as others have pointed out these other cases can cause a lot of existing
code to break whereas a change to String should not.