Out on HF and heard nobody, but didn't call CQ? Nobody heard you either. 73 de N7GH
"Il y a peu de choses qui me soient impossibles..."
Les Morgan wrote:Please give a listing for your CustomClass class.
Henry Wong wrote:
Can you provide a SSCCE that demonstrates your issue?
Henry
Paul Clapham wrote:Well, your CustomHashMapIntegerKey class is just a wrapper for Integer, except for the defect that it's a mutable class. So if you call the setKey() method of a CustomHashMapIntegerKey object then that object's hash code changes. And that's a Very Bad Thing for an object which is to be used as the key of a Map.
So don't use that. Go back to using Integer as your key, since Integer should work perfectly well as a key and your CustomHashMapIntegerKey has at least one flaw and possibly others.
And then as for your problem, it looks like you're going to have to come up with your own SSCCE since we don't know anything except that redacted code fragment you posted. For all we know the code is being run in multiple threads and there are race conditions happening, but you didn't say anything about where the code is running either.
Muhammad Anfal wrote:I wrote something similar to that as well just to test and it is working well, but when I run same code in the app it start producing that bug. I dunno how and I am quite curious to find it out.
There are three kinds of actuaries: those who can count, and those who can't.
Piet Souris wrote:A sound advice, although I doubt if the problem is in this part.
I just had a look at the 'DepartmentItemHolder' class, and the
DepartmentItemDataObject, and I see that there is a method that
sets the 'key' of such a 'DepartmentItemDataObject'.
So it is possible that you put a DepartmentItemHolder object, with a
given key, into your Map, then later change that key, and, again later,
you use that key to retrieve the List. But since the key has changed it
will in all likelyhood be another List. Well, maybe you can have a look if
that is happening somewhere.
Muhammad Anfal wrote:I just had a thought, assume if I were to supply 2 different person objects with different ids simultaneously to this line of code
I will end up entering them in the same list instead of their separate lists? assuming both the code and supplier of person objects are working on the main ui thread.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Muhammad Anfal wrote:I made a custom class just to check if hashCode() and equals() are being called by HashMap.
Paul Clapham wrote:
Muhammad Anfal wrote:I made a custom class just to check if hashCode() and equals() are being called by HashMap.
Just for future reference: It does occasionally happen that code in the standard Java API contains bugs. But when you make the hypothesis that an API bug is the source of your code's problems, the chances are very high that you're wasting your time. Especially when you're talking about code which has been in the language since the beginning of time. So when you're chasing down a bug, you should always assume that it's your fault.
Winston Gutkowski wrote:
Muhammad Anfal wrote:I just had a thought, assume if I were to supply 2 different person objects with different ids simultaneously to this line of code
I will end up entering them in the same list instead of their separate lists? assuming both the code and supplier of person objects are working on the main ui thread.
No you won't. If the ID is different, you will add it to a different List.
Which begs the question: Where does your Integer "ID" come from, and what does it mean?
However, even without that, an alternative to what you've been doing is as follows:which saves a fair bit of faffing around.
Winston
Popeye has his spinach. I have this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|