I have a method do remove a specific element from a list. It iterates through a list and when it finds the one I want to eliminate, it adds that element to another list (in this example, ArrayList deadVampires. Sometimes it removes the element, sometimes it does not.
Here is the code (the prints are just so I can follow the array content before and after using removeAll().:
My guess is that there's something wrong with the equals() method in your Vampire class. That's what gets used by the removeAll() method to decide which objects to remove. So could you show us that method?
Ted Schrey wrote:I have it set to make two vampires equal if their coordinates are equal...
Yeah, that doesn't sound like a good idea to me either. Having said that I don't know what you should use instead, but as long as object identity (which is what you have when you remove the equals() method) is working for you, you might as well keep it that way.
Not true. The identity check is usually just a performance booster for objects with expensive comparisons. An object will *always* be equal to itself, regardless of an identity check, otherwise the symmetricity requirement will probably also fail.
Winston Gutkowski wrote:It is absolutely required if you use super.equals() because of the way Object.equals() is implemented.
Can you give me an example where you would use super.equals()? As far as I know, you can not override equals() meaningfully more than once (overriding Object.equals()), without breaking transitivity. This is the reason why you should make an implementation of equals() final, unless you allow sub-types to improve performance.
Nevermind, you can do this as long as you use getClass() instead of instanceof. I'm still not convinced you need to compare for identity first though.
This current discussion, regarding reflexivity, I assume stems from the belief that the same object is being compared? And I assume it is based on the fact that the print out has the same hashcode?
How do we know that the same object is being compared? The OP overridden the hashCode() method, and although complete code was not shown, probably didn't override the toString() method. These could be different objects with the same hash code.
If I had to speculate on the issue, I would say that the OP probably declared the row and col variables as Integer references. This way, they could fail to be equal (as it is a reference comparison), and yet, the hashCode() method would still work (due to autoboxing).
[EDIT: in reading again, the OP did mention that it started working when the equals() method was removed... so, my speculation is likely wrong ... ]
In that case the equals method was incorrectly overridden beforehand.
You need to decide what to do with your equals method, which means you start by deciding under which circumstances two objects are “equal” to each other. In some cases and maybe this is such an instance, all objects of a class are implicitly different from one another.
Could you hold this puppy for a sec? I need to adjust this tiny ad: