Hi everyone. In K&B, page 614 the following code is given:
and the answer: As the code stands the output will be 3.
As the hashcode of different objects is not necessarily different, the output could as well be 2, couldn't it?
I am feeling really confused at the moment about this question and two others from the thread-chapter. (If a thread calls the wait-method on an object it holds the lock on or is set to sleep, it still may wake up without explicitly being notified from written code? If so, I am also in doubt with the answers to question 9 and 17 from the threads chapter) [ May 30, 2007: Message edited by: Sasha Ruehmkorf ]
I am feeling really confused at the moment about this question
There is nothing to confuse in this.
In the first case, as the hascode is not explicitly defined t1, t2 and t3 will go in to three diffrent buckets. Thats the reason why the size is 2.
where as in second case, when the hascode is defined, t1 and t2 will go to one and t3 to other. And this is why the answer is 2. Ranchers, Correct me if i am wrong. [ May 30, 2007: Message edited by: Prasad Tamirisa ]
Default hashCode() that you get from the Object class hashCode() definition, each object will have different hashCode.
So I don't think, the size will come 2. You have commented hashCode() definition of your class so therefore size is 3. Each object has different hashCode irrespective of what the object encapsulate ("Monday" by two objects).
I think your doubt runs around, the hashCode() from the Object class may return same hashCode() for more than two objects, but it is not like as I think because it is derived from the physical address of the object and it will be different for objects created using "new" operator that is the way to create objects of our class (not talking about wrapper classes).
I think your doubt runs around, the hashCode() from the Object class may return same hashCode() for more than two objects,
Exactly From the API:
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects.
Maybe this sounds nickpicking, but it really confuses me, as especially regarding GC and Threads I learned: It's not about what is likely to happen, but it's about what is guaranteed. So starting a thread the job of which is to print "one" and then immediately after that starting a thread the job of which is to print "two", the output "onetwo" is not determined. OK, got it. If I try it 1000000 times, the output will always be "onetwo", but that would not be the correct answer in the exam. But if I follow this road, my answers to the 3 mentioned questions above would not match the ones given in K&B...
It would be better I you had started the threads doubt in new thread.
I agree, sorry... My Doubts: HashCode) Different Objects have different hashcode -> Very likely but in very special cases this could be wrong
Thread Question 9) Why shouldn't the thread spontaneously wake up while in waiting-state. As K&B wrote: "Sometimes the JVM may call notify() for reasons of its own." So output "1 2 3" is an option.
Thread Question 17) Nearly the same. If a spontaneous wakeup happens before the hardy-thread causes the exception, "B" would be printed also. (So my choice was G) for this question) [Edit] -> Forget about this one, explanation was wrong and I am not sure if there could be any interruption waking up laurel, but maybe? [ May 30, 2007: Message edited by: Sasha Ruehmkorf ]
"Sometimes the JVM may call notify() for reasons of its own." So output "1 2 3" is an option.
I don't know but this may be an exceptional (I may call it special scenario), exam is very specific to guaranteed things and we are given number of options to choose it you had to choose two from them all, you may choose 1 2 3 also as per your description says that JVM may call notify, but I am not sure about that.
When people don’t understand what you are doing they call you crazy. But this tiny ad just doesn't care: