• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

problems with hashset

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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


}

}
}
 
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is a suggestion:
You wrote:

Solution 2:

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 ]
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:

or more generally

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
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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

Solution 2:

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
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1067
2
IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:

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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic