problems with hashset

[ciaran Hurst]

hi,
i have a problem with hashset. I need to use them cause i cannot afford duplicate entries. But i need to get an element out of the hashset change it and put it back into the hashset in the same place. I wrote a simple program below. How would i for example check for a value of 3 if its 3 change it to some other number an insert it in the same place in the hashset.
public class test{
private HashSet theset, set2;
public test(){
theset = new HashSet();
set2 = new HashSet();
fillset();
set2 = theset;
printset();
}
public static void main(String[] args) {
test atest = new test();
}
public void printset(){
Iterator iter = set2.iterator();
while(iter.hasNext()){
System.out.println("the value is" + iter.next());
}
}
public void fillset(){
theset.add("1");
theset.add("2");
theset.add("3");
theset.add("4");
theset.add("5");
theset.add("6");
}
public void changeElement(){
Iterator iter = set2.iterator();
while(iter.hasNext()){
//HOW DO I CHANGE "3" WITHOUT JUMPING AHEAD ONE
// IE I CANNOT USE NEXT


}

}
}

[Rodney Woodruff]

Here is a suggestion:
You wrote:

public void changeElement(Object original, Object newObject){
HashSet newHashSet;
//First make sure the list contains the object
if(!set2.contains(original))
return;
Iterator iter = set2.iterator();
//Create a Hash that is the same size as the hash that will be cloned
newHashSet = new HashSet(set2.size());
//now do a shallow copy of set2
while(iter.hasNext()){
Object temp = iter.next();
if(temp.equals(original)){
System.out.println("\nChanging the Object");
temp = newObject;
}
newHashSet.add(temp);
}
//discard the old set2 HashSet and replace it with the HashSet
//that contains your new values
set2 = newHashSet;
//This is not necessary but has been added for clarity.
newHashSet = null;
}

Solution 2:

public void changeElement(Object original, Object newObject){
HashSet newHashSet;
//First make sure the list contains the object
if(!set2.contains(original))
return;
Iterator iter = set2.iterator();
//Create a Hash that is the same size as the hash that will be cloned
newHashSet = new HashSet(set2.size());
//now do a shallow copy of set2
while(iter.hasNext()){
Object temp = iter.next();
if(temp.equals(original)){
System.out.println("\nChanging the Object");
set2.remove(original);
set2.add(newObject);
return;
}
}
}

Can you tell me why you can't call next?
[ March 07, 2003: Message edited by: Rodney Woodruff ]
[ March 07, 2003: Message edited by: Rodney Woodruff ]

[Jim Yingst]

i have a problem with hashset. I need to use them cause i cannot afford duplicate entries. But i need to get an element out of the hashset change it and put it back into the hashset in the same place. I wrote a simple program below. How would i for example check for a value of 3 if its 3 change it to some other number an insert it in the same place in the hashset.
This makes no sense. If you change the value, you can't possibly put it "in the same place" in the HashSet - the position of an element in a HashSet is determined by its hashCode() method, and if you change the value of an object you will almost always change its hash code. Moreover there's absolutely no reason to pay attention to the "position" of an object in a HashSet - it's an internal implementation detail, and none of our business. The HashSet will put things wherever it wants to. We just need to know if an object is in the set or not - where it is is irrelevant.
It sounds like what you want to do is simply remove the old object and add a new one instead:

        if (set.remove("3"))
            set.add("3 (new and improved)");

or more generally

    public boolean replace(Object ob1, Object ob2) {
        if (set.remove(ob1)) {
            if (set.add(ob2))
                return true;
            set.add(ob1);
        }
        return false;
    }

Here if the replacement fails for any reason (either ob1 is not in the set, or ob2 was already in the set and cannot be added again) then the set is restored to its previous state and false is returned.
That's it. No iterators needed. No copying of contents of a set (unless you have some other reason to do this, which you haven't mentioned).

[Rodney Woodruff]

Pay attention to Jim. I don't know what I was thinking. My solution works but is way overkill for what you need to do.

[ciaran Hurst]

Originally posted by Rodney Woodruff:
Here is a suggestion:
You wrote:

public void changeElement(Object original, Object newObject){
HashSet newHashSet;
//First make sure the list contains the object
if(!set2.contains(original))
return;
Iterator iter = set2.iterator();
//Create a Hash that is the same size as the hash that will be cloned
newHashSet = new HashSet(set2.size());
//now do a shallow copy of set2
while(iter.hasNext()){
Object temp = iter.next();
if(temp.equals(original)){
System.out.println("\nChanging the Object");
temp = newObject;
}
newHashSet.add(temp);
}
//discard the old set2 HashSet and replace it with the HashSet
//that contains your new values
set2 = newHashSet;
//This is not necessary but has been added for clarity.
newHashSet = null;
}

Solution 2:

public void changeElement(Object original, Object newObject){
HashSet newHashSet;
//First make sure the list contains the object
if(!set2.contains(original))
return;
Iterator iter = set2.iterator();
//Create a Hash that is the same size as the hash that will be cloned
newHashSet = new HashSet(set2.size());
//now do a shallow copy of set2
while(iter.hasNext()){
Object temp = iter.next();
if(temp.equals(original)){
System.out.println("\nChanging the Object");
set2.remove(original);
set2.add(newObject);
return;
}
}
}

Can you tell me why you can't call next?
[ March 07, 2003: Message edited by: Rodney Woodruff ]
[ March 07, 2003: Message edited by: Rodney Woodruff ]

cheers got it

[Stan James]

As mentioned before, HashSet is unordered. The doc says "in particular, it does not guarantee that the order will remain constant over time."
If you really care about the order of things and want to replace the current object in position three with a new object, see LinkedHashSet.
Because there are ten collections classes on three interfaces and my brain is feeble, I made aCollections Framework crib sheet.

[William Barnes]

Nice crib sheet Stan - except you might want to also mention that those "historic" classes are thread-safe by default. Not a bad reason to keep using them.

[Jim Yingst]

I disagree, William. (Or should that be "I think Willims is wrong"?) The legacy collection classes are bêtes noires for Peter den Haan and myself for several reasons - this is the biggest one: Often the synchronization provided by those classes is not at the right level to really ensure thread safety, and so using those classes gives people a false sense of security. For example:

    for (int i = 0, i < vector.size(); i++)
    {
        Object obj = vector.get(i);
        doSomethingWith(obj);
    }

Although Vector is "thread safe", nothing prevents another thread from accessing the Vector in between invocations of size() and get(). So it's possible that an element could be removed just before it's accessed, leading to an ArrayIndexOutOfBoundsException. Or other strange things could happen, like elements being accessed twice, or skipped entirely, because elements were added or removed while the iteration was going on. The same problems exist if you use an Enumeration or Iterator. The usual way to solve this is to explicitly synchronize on the Vector (or some other appropriate object) somewhere outside the iteration loop. Once you have to do this, there's really no point in also having synchronization on the size() and get() methods - it's just making the JVM do a little more work, with no benefit.
In general, I recommend using explicit synchronized blocks to put in synchronization as needed - and think carefully about where this should be. Taking the shortcut of using "thread-safe" classes often just encourages carelessness, IMO. It's true that there are some cases where using a Vector may turn out to be slightly faster than using explicit synchronization blocks (or alternately, using Collections.synchronizedList() and the like). But it's pretty rare that this sort of optimization makes a notable difference, and usually it's much more important to ensure your "thread safety" is really correct. Plus by choosing judiciously exactly where to synchronize, you can often get better performance gains than by simply using Vector et al.