• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Knute Snortum
  • Bear Bibeault
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Tim Holloway

final classes should override equals

 
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I read somewhere that final classes should override the equals method in the Object class. This means that equals semantics is the same as ==, and probably a mistake. For instance:



but could someone please justify why exactly?
 
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Where did you read or hear this? If an inherited method is correct why should it be overridden?
 
Rahul Kakkar
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In an open source software called findbugs. For their detector UseObjectEquals, the description states:

"This detector looks calls to equals(java.lang.Object) on arrays, or final classes that do not override the equals method in the Object class. This means that equals semantics is the same as ==, and probably a mistake."
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think plenty of java programmers would have problems with that "probably".
In the code I write, I distinguish between values classes, which are
classes like String, Integer, Date, Point, etc... and other classes.
Value classes usually need to override equals, but that findbugs program
is trying to be as picky as possible, just to locate "possible", rather
than "probable" bugs. Maybe it, when it is nitpicking, should label
what it finds as "highly likely", "probably" and "only possibly" a bug...
 
Rahul Kakkar
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hmmm...
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Rahul Kakkar:
In an open source software called findbugs. For their detector UseObjectEquals, the description states:

"This detector looks calls to equals(java.lang.Object) on arrays, or final classes that do not override the equals method in the Object class. This means that equals semantics is the same as ==, and probably a mistake."



Read this carefully - it doesn't say that it detects final classes that don't implement equals, but *calls of the equals method* on final classes that don't implement it. Because the class doesn't implement equals and because it is final *and therefore equals can't be implemented by a subclass*, it is likely a bug.

With other words, only for final classes you can tell whether the instance you call equals on will have that method redefined from the default implementation.

Final classes without an equals method are fine as long as you don't call equals on them.
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Rahul Kakkar:
I read somewhere that final classes should override the equals method in the Object class. This means that equals semantics is the same as ==, and probably a mistake. For instance:



but could someone please justify why exactly?



This is the industry's feeble attempts to misacknowledge the defectiveness of concrete inheritance (failure to acknowledge constant non-zero time) and attribute it something else (such as "final classes need to do 'such and such'") in order to meet marketing agendas, etc. (speculative). Are you asking for reality? or perceived reality? The very common literature portray the latter quite well.
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
Final classes without an equals method are fine as long as you don't call equals on them.



True story: I don't know why but I automatically compare java.lang.Class
instances using equals, not ==. Is this a bug in my code?
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff - no, those are equivalent (as long as the first class is not null). You're fine. Ilja's comment correctly says that if you don't call equals, you're OK. But if you do, then whether it's OK or not depends on the class and how it was designed. Some classes are designed such that the default implemenation from Object is entirely correct. The class Class is one of them.

[Ilja]: With other words, only for final classes you can tell whether the instance you call equals on will have that method redefined from the default implementation.

Well, you might also have a nonfinal class which declares a final equals() method. JDK 5's Enum class is an example. The only reason they override equals() there is to make the method final - other than that, the original implementation from Object was fine.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jim Yingst:

Well, you might also have a nonfinal class which declares a final equals() method. JDK 5's Enum class is an example. The only reason they override equals() there is to make the method final - other than that, the original implementation from Object was fine.



Ah, true, I was sloppy. Bad me...

Of course this doesn't help the findbugs tool at all, because it wants to warn when the equals method *is not* implemented.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!