I have an arrayList called A, say, which is non-empty.
I create another arrayList, B, and put in some elements of A.
for(someobject obj : A){
if(some_condition_is_met)
B.add(obj);
}
Then I do some stuff with B (never modifying, shuffling, or deleting objects from it. I pick an element of B, say B.get(i).
Now, I want to find B.get(i)'s position in A.
I tried
for(someobject obj : A){
if(obj.equals(B.get(i))
return A.lastIndexOf(obj);
}
return null;
But this kept returning null. That is, "equals" doesn't match the objects.
SO in my frustration I tried:
return A.get(A.lastIndexOf(B.get(i));
which caused an ArrayINdexOutOfBounds exception.
Any ideas what I should do? I've got a feeling I'm missing something obvious.
One more point - this is an incredibly simplified explanation of what I'm doing. In the above example creating B might seem pointless, but it is necessary.
ANSWERS TO QUESTIONS:
1)The objects are custom objects. Ah,... I didn't override equals. That might be it.
2) I can be sure any object in B mst B in A because on creating B, first I remove all from it, just in case, then I add only object from A and I do not tamper with the objects once in B.
The principle of what you are trying to do should work. I could make the quibble that there is little point in doing the FOR loop to search through A to find an instance of the object from B, and then doing a lastIndexOf on it. lastIndexOf will iterate through A anyway. You are searching for something, and then when you find it you are just leaving it where it lies and searching for it all over again. (Admittedly, your first search is from the beginning of A while lastIndexOf will search from the end. So this is like looking for your car keys starting in the basement and working up to the attic. Then when you find them, you leave them there, and then go to the attic and start the search again working your way down to the basement.)
I suspect that the problem is not in the concept, but in the details. You might show the actual code. If the code is too complex, try simplifying it down to the essentials and see if the error still occurs.
One possibility: Do you really add the object from A to B directly? Or are you creating a new object for B that is a copy of the object from A? If the latter, then unless you override equals() it's not going to work, because the default equals() for a user-defined object just checks if they are the same instance, not "equivalent" objects.
Where are you getting i from in your second code block, and are you checking it against the size of B? i.e.
for(someobject obj : A){
if(obj.equals(B.get(i))
return A.lastIndexOf(obj);
}
return null;
What was the value of i, the size of B when you did return A.get(A.lastIndexOf(B.get(i)); and got the ArrayIndexOutOfBounds?
Do this simple test after you populate A and B, to check that they have the expected values ...
for (Object o : B)
{
System.out.println(A.lastIndexOf(o));
}
If you have problems at this stage, you likely have some problem constructing your objects. Also make sure you're not swallowing exceptions anywhere.
Override equals() and hashcode() methods in your object
#Override
public boolean equals(Object o) {
boolean result = false;
if (o instanceof Someobject ) {
Someobject other = (Someobject ) o;
result = attribute.equalsIgnoreCase(other.attribute);
}
return result;
}
#Override
public int hashCode() {
return attribute.hashCode();
}
It seems that B contains different objects from A. Are you sure, that equals method is correct in your objects? And you haven't modified objects in B (or A)?
Is it possible that some_condition_is_met is always false ? If so, this would perfectly explain the whole use case -- except for B.get(i) which would always return an IndexOutOfBoundsException no matter what i is.
So, after running the first loop, can you try a B.isEmpty() check ?
You need to make sure two things are happening here.
Write your objects equals and hashcode functions correctly.
Use .indexOf() instead
If you post some more code I am sure we can help more.
Did you implement equals() and hashcode() in the class being added to the list?
Sounds like the standard deep/shallow copy issue and exactly what are you comparing - addresses or values of the object in the ArrayList. Determine that and follow the advice of others about the equals and hashCode overrides
Related
Is there any Equalator mechanism like Comparator so I can have different equals for coparing lists?
EDIT: My goal is to differentiate between current list1.equals(list2) which checks if its a shallow copy or also a deep copy with all objects a.equals(b) and list1.identical(list2) which checks if its simply shallow copy with unmodified listing
All these lists are from the same model. Some are copies of themselves so they hold the pointer to same objects, and others are deep copies so hierarchy is totally replicated, because they have updates in content, not just in structure.
I find myself oftenly makin list1.equals(list2) but I need a mechanism for telling if both are TOTAL copies (same objects in same order for collections) or sometimes if they are LOGICAL copies (through my own implemented logic equals), so list would call equals and objects should implement something more than a==b.
My problem is there is no Equalator interface, and if I override objects equals to I loose the capability of comparing by TOTAL EQUAL (a==b)
For example, this would be nice;
Collections.equal(l1,l2,new Equalator(){
#Override public boolean equals(Obj1,Obj2){
//Default lists comparison plus commparison of objects based on
return (obj1.propertyX() == obj2.propertyX());
}
});
and still I could do list1.equals(list2) so they use default equals (obj1==obj2) and this would be only true if contained objects are exactly the same.
First operation is useful for checking if list (which could be an updated list with totally recreated objects from the model) is still equals to the old list.
Second operation is useful for checking if list (which was a shallow copy of the old current version of data model), it does not contain any transcendent change from moving it around inside the code when it was the udpdated version.
EDIT: A very good example would be having a list of Point(x,y). We should be able to know if both list are equal because they are exactly same set of points or equal because the points they contain are equal in a logical way. If we could implement both phyEqual and logEqual to object, and have both methods in any object so list.phyEqual(list2) or list1.logEqual(list2)
Your question doesn't really come across clearly, at least to me. If this doesn't answer it properly, could you re-word a little bit?
Within a given Collection concrete type, most equals implementations already do what you hint at.
For instance:
public boolean equals(Object o) {
if (o == this)
return true;
In this case, something like this might make sense.
You can easily override this:
#Override
public boolean equals(Object o) {
if (o.getPrimaryKey() == this.getPrimaryKey())
return true;
return super().equals(o);
[test for nulls should be added]
If you are creating standard collections, you can even anonymously override the equals method during construction.
If this doesn't do what you want, you could extend Collections yourself and override any of the methods there to do a similar thing.
Does that help?
A late answer, but maybe it will be useful for someone...
The Guava Equivalence class is the same for equivalence as Comparator for comparing. You would need to write your own method for comparing the lists (there is no support in Guava for that), but then you could call this method with various equivalence-definitions.
Or you can roll your own interface:
interface Equalator<T> {
boolean equals(T o1, T o2);
}
Again, you need to write your (trivial) method
boolean <T> listEquals(List<T> list1, List<T> list2, Equalator<T> equalator) {
...
}
...but then you can reuse it with different ListEqualator implementations.
I have an object in a LinkedHashSet that implements equals, hashCode and compareTo (in a superclass) but when I try to remove that exact object from the set set.remove(obj) the remove method returns false and the object remains in the set. Is the implementation of LinkedHashSet supposed to call the equals() method of its objects? Because it doesn't. Could this be a java bug? I'm running 1.6.0_25.
My guess would be that your object's hashCode() implementation is returning a different value than when you added the object to the set.
LinkedHashSet works fine for me:
import java.util.*;
public class Test {
public static void main( String[] args ) {
LinkedHashSet<String> lhs = new LinkedHashSet<String>();
String s = "hi";
lhs.add( s );
System.out.println( lhs );
lhs.remove( s );
System.out.println( lhs );
}
}
Perhaps you're passing in a reference to a different object to the remove method? Are you sure you didn't change the reference in any way?
Also make sure that hashCode() returns the same value when you insert it as when you are trying to remove it.
The chances of this being a bug in LinkedHashSet are infinitessimnally small. You should dismiss this as a plausible explanation of your problem.
Assuming that this is a bug in your code, then it could be due to a number of things. For instance:
Your equals and hashCode methods are returning contradictory answers for the object.
Your equals or hashCode methods depend on mutable fields and those fields are being changed while the object is in the set. (For instance, if the hashcode value changes, the object is likely to be on the wrong hash chain, causing the remove method to not find it.)
You have declared the equals method as an overload, not an override of equals(Object). (That could explain why your equals is not being called ... assuming that your assertion is factually correct.)
The object you are trying to remove is (in reality) not the one you inserted.
Something else has already removed the object.
You are running a different version of some class that does not match the source code you have been examining.
Now, I know that you have dismissed some of these explanations. But that may have been premature. Review the evidence that you based that dismissal on.
Another approach you could use is to use a Java debugger to forensically examine the data structures (e.g. the innards of the LinkedHashSet) and single-step the code where the deletion is supposed to be happening.
I want to handle a set of objects of class (MyClass) in a HashSet. When I try to add an object that already exists (relying on equals an hashCode of MyClass), the method return false. Is there a way/method to get in return the actual object that already exists?
Please give me any advice to handle that collection of object be able to get the existing object in return when add returns false?
Just check if the hashset contains you're object:
if (hashSet.contains(obj)) {
doWhateverWith(obj);
}
Short of iterating over the set, no, there is no way to get the existing member of the set that is equal to the value just added. The best way to do that would be to write a set wrapper around HashMap that maps each added value to itself.
If equals(..) returns true, then the objects are the same, so you can use the one you are trying to add to the set.
Why would you let it return the object which you're trying to add? You already have it there!
Just do something like:
if (!set.add(item)) {
// It already contains the item.
doSomethingWith(item);
}
If that does not achieve the desired result, then it simply means that the item's equals() is poorly implemented.
One possible way would be:
myClass[] myArray = mySet.toArray(new myClass[mySet.size]);
List myList = Arrays.asList(myArray);
MyClass myObject = myList.get(myList.indexof(myObject));
But of course as some people pointed out if it failed to get inserted, then that element is the element you are looking for, unless of course that you want what is stored in that memory location, and not what the equals and hashCode tells you, i.e. not the logically equal object, but the == object.
When using a HashSet, no, as far as I know you can't do that except by iterating over the whole thing and calling equals() on each one. You could, however, use a HashMap and just map every object to itself. Then call put(), which will return the previously mapped value, if any.
http://download.oracle.com/javase/6/docs/api/java/util/HashSet.html#contains(java.lang.Object)
You can use that method to check if you like; but the thing you have to keep in mind is that you already have the object that exists.
I'm having problems with Iterator.remove() called on a HashSet.
I've a Set of time stamped objects. Before adding a new item to the Set, I loop through the set, identify an old version of that data object and remove it (before adding the new object). the timestamp is included in hashCode and equals(), but not equalsData().
for (Iterator<DataResult> i = allResults.iterator(); i.hasNext();)
{
DataResult oldData = i.next();
if (data.equalsData(oldData))
{
i.remove();
break;
}
}
allResults.add(data)
The odd thing is that i.remove() silently fails (no exception) for some of the items in the set. I've verified
The line i.remove() is actually called. I can call it from the debugger directly at the breakpoint in Eclipse and it still fails to change the state of Set
DataResult is an immutable object so it can't have changed after being added to the set originally.
The equals and hashCode() methods use #Override to ensure they are the correct methods. Unit tests verify these work.
This also fails if I just use a for statement and Set.remove instead. (e.g. loop through the items, find the item in the list, then call Set.remove(oldData) after the loop).
I've tested in JDK 5 and JDK 6.
I thought I must be missing something basic, but after spending some significant time on this my colleague and I are stumped. Any suggestions for things to check?
EDIT:
There have been questions - is DataResult truly immutable. Yes. There are no setters. And when the Date object is retrieved (which is a mutable object), it is done by creating a copy.
public Date getEntryTime()
{
return DateUtil.copyDate(entryTime);
}
public static Date copyDate(Date date)
{
return (date == null) ? null : new Date(date.getTime());
}
FURTHER EDIT (some time later):
For the record -- DataResult was not immutable! It referenced an object which had a hashcode which changed when persisted to the database (bad practice, I know). It turned out that if a DataResult was created with a transient subobject, and the subobject was persisted, the DataResult hashcode was changed.
Very subtle -- I looked at this many times and didn't notice the lack of immutability.
I was very curious about this one still, and wrote the following test:
import java.util.HashSet;
import java.util.Iterator;
import java.util.Random;
import java.util.Set;
public class HashCodeTest {
private int hashCode = 0;
#Override public int hashCode() {
return hashCode ++;
}
public static void main(String[] args) {
Set<HashCodeTest> set = new HashSet<HashCodeTest>();
set.add(new HashCodeTest());
System.out.println(set.size());
for (Iterator<HashCodeTest> iter = set.iterator();
iter.hasNext();) {
iter.next();
iter.remove();
}
System.out.println(set.size());
}
}
which results in:
1
1
If the hashCode() value of an object has changed since it was added to the HashSet, it seems to render the object unremovable.
I'm not sure if that's the problem you're running into, but it's something to look into if you decide to re-visit this.
Under the covers, HashSet uses HashMap, which calls HashMap.removeEntryForKey(Object) when either HashSet.remove(Object) or Iterator.remove() is called. This method uses both hashCode() and equals() to validate that it is removing the proper object from the collection.
If both Iterator.remove() and HashSet.remove(Object) are not working, then something is definitely wrong with your equals() or hashCode() methods. Posting the code for these would be helpful in diagnosis of your issue.
Are you absolutely certain that DataResult is immutable? What is the type of the timestamp? If it's a java.util.Date are you making copies of it when you're initializing the DataResult? Keep in mind that java.util.Date is mutable.
For instance:
Date timestamp = new Date();
DataResult d = new DataResult(timestamp);
System.out.println(d.getTimestamp());
timestamp.setTime(System.currentTimeMillis());
System.out.println(d.getTimestamp());
Would print two different times.
It would also help if you could post some source code.
You should all be careful of any Java Collection that fetches its children by hashcode, in the case that its child type's hashcode depends on its mutable state. An example:
HashSet<HashSet<?>> or HashSet<AbstaractSet<?>> or HashMap variant:
HashSet retrieves an item by its hashCode, but its item type
is a HashSet, and hashSet.hashCode depends on its item's state.
Code for that matter:
HashSet<HashSet<String>> coll = new HashSet<HashSet<String>>();
HashSet<String> set1 = new HashSet<String>();
set1.add("1");
coll.add(set1);
print(set1.hashCode()); //---> will output X
set1.add("2");
print(set1.hashCode()); //---> will output Y
coll.remove(set1) // WILL FAIL TO REMOVE (SILENTLY)
Reason being is HashSet's remove method uses HashMap and it identifies keys by hashCode, while AbstractSet's hashCode is dynamic and depends upon the mutable properties of itself.
Thanks for all the help. I suspect the problem must be with equals() and hashCode() as suggested by spencerk. I did check those in my debugger and with unit tests, but I've got to be missing something.
I ended up doing a workaround-- copying all the items except one to a new Set. For kicks, I used Apache Commons CollectionUtils.
Set<DataResult> tempResults = new HashSet<DataResult>();
CollectionUtils.select(allResults,
new Predicate()
{
public boolean evaluate(Object oldData)
{
return !data.equalsData((DataResult) oldData);
}
}
, tempResults);
allResults = tempResults;
I'm going to stop here-- too much work to simplify down to a simple test case. But the help is miuch appreciated.
It's almost certainly the case the hashcodes don't match for the old and new data that are "equals()". I've run into this kind of thing before and you essentially end up spewing hashcodes for every object and the string representation and trying to figure out why the mismatch is happening.
If you're comparing items pre/post database, sometimes it loses the nanoseconds (depending on your DB column type) which can cause hashcodes to change.
Have you tried something like
boolean removed = allResults.remove(oldData)
if (!removed) // COMPLAIN BITTERLY!
In other words, remove the object from the Set and break the loop. That won't cause the Iterator to complain. I don't think this is a long term solution but would probably give you some information about the hashCode, equals and equalsData methods
The Java HashSet has an issue in "remove()" method. Check the link below. I switched to TreeSet and it works fine. But I need the O(1) time complexity.
https://bugs.openjdk.java.net/browse/JDK-8154740
If there are two entries with the same data, only one of them is replaced... have you accounted for that? And just in case, have you tried another collection data structure that doesn't use a hashcode, say a List?
I'm not up to speed on my Java, but I know that you can't remove an item from a collection when you are iterating over that collection in .NET, although .NET will throw an exception if it catches this. Could this be the problem?
Let's say I have this type in my application:
public class A {
public int id;
public B b;
public boolean equals(Object another) { return this.id == ((A)another).id; }
public int hashCode() { return 31 * id; //nice prime number }
}
and a Set<A> structure. Now, I have an object of type A and want to do the following:
If my A is within the set, update its field b to match my object.
Else, add it to the set.
So checking if it is in there is easy enough (contains), and adding to the set is easy too. My question is this: how do I get a handle to update the object within? Interface Set doesn't have a get method, and the best I could think of was to remove the object in the set and add mine. another, even worse, alternative is to traverse the set with an iterator to try and locate the object.
I'll gladly take better suggestions... This includes the efficient use of other data structures.
Yuval =8-)
EDIT: Thank you all for answering... Unfortunately I can't 'accept' the best answers here, those that suggest using a Map, because changing the type of the collection radically for this purpose only would be a little extreme (this collection is already mapped through Hibernate...)
Since a Set can only contain one instance of an object (as defined by its equals and hashCode methods), just remove it and then add it. If there was one already, that other one will be removed from the Set and replaced by the one you want.
I have code that does something similar - I am caching objects so that everywhere a particular object appears in a bunch of different places on the GUI, it's always the same one. In that case, instead of using a Set I'm using a Map, and then I get an update, I retrieve it from the Map and update it in place rather than creating a new instance.
You really want to use a Map<Integer,A>, not a Set<A>.
Then map the ID (even though it's also stored in A!) to the object. So storing new is this:
A a = ...;
Map<Integer,A> map = new HashMap<Integer,A>();
map.put( a.id, a );
Your complete update algorithm is:
public static void update( Map<Integer,A> map, A obj ) {
A existing = map.get( obj.id );
if ( existing == null )
map.put( obj.id, obj );
else
existing.b = obj.b;
}
However, it might be even simpler. I'm assuming you have more fields than that in A that what you gave. If this is not the case, just using a Map<Integer,B> is in fact what you want, then it collapses to nothing:
Map<Integer,B> map = new HashMap<Integer,B>();
// The insert-or-update is just this:
map.put( id, b );
I don't think you can make it any easier than using remove/add if you are using a Set.
set.remove(a);
set.add(a);
If a matching A was found it will be removed and then you add the new one, you don't even need the if (set.contains(A)) conditional.
If you have an object with an ID and an updated field and you don't really care about any other aspects of that object, just throw it out and replace it.
If you need to do anything else to the A that matches that ID then you'll have to iterate through the Set to find it or use a different Container (like the Map as Jason suggested).
No one has mentioned this yet, but basing hashCode or equals on a mutable property is one of those really, really big things that you shouldn't do. Don't muck about with object identity after you leave the constructor - doing so greatly increases your chances of having really difficult-to-figure out bugs down the road. Even if you don't get hit with bugs, the accounting work to make sure that you always properly update any and all data structures that relies on equals and hashCode being consistent will far outweigh any perceived benefits of being able to just change the id of the object as you run.
Instead, I strongly recommend that you pass id in via the constructor, and if you need to change it, create a new instance of A. This will force users of your object (including yourself) to properly interact with the collection classes (and many others) that rely on immutable behavior in equals and hashCode.
What about Map<A,A> I know it's redundant, but I believe it will get you the behavior you'd like. Really I'd love to see Set have a get(Object o) method on it.
You might want to generate a decorator called ASet and use an internal Map as the backing data structure
class ASet {
private Map<Integer, A> map;
public ASet() {
map = new HashMap<Integer, A>();
}
public A updateOrAdd(Integer id, int delta) {
A a = map.get(a);
if(a == null) {
a = new A(id);
map.put(id,a);
}
a.setX(a.getX() + delta);
}
}
You can also take a look at the Trove API. While that is better for performance and for accounting that you are working with primitive variables, it exposes this feature very nicely (e.g. map.adjustOrPutValue(key, initialValue, deltaValue).
It's a bit outside scope, but you forgot to re-implement hashCode(). When you override equals please override hashCode(), even in an example.
For example; contains() will very probably go wrong when you have a HashSet implementation of Set as the HashSet uses the hashCode of Object to locate the bucket (a number which has nothing to do with business logic), and only equals() the elements within that bucket.
public class A {
public int id;
public B b;
public int hashCode() {return id;} // simple and efficient enough for small Sets
public boolean equals(Object another) {
if (object == null || ! (object instanceOf A) ) {
return false;
}
return this.id == ((A)another).id;
}
}
public class Logic {
/**
* Replace the element in data with the same id as element, or add element
* to data when the id of element is not yet used by any A in data.
*/
public void update(Set<A> data, A element) {
data.remove(element); // Safe even if the element is not in the Set
data.add(element);
}
}
EDIT Yuvalindicated correctly that Set.add does not overwrite an existing element, but only adds if the element is not yet in the collection (with "is" implemented by equals)