mike hanser

Greenhorn
+ Follow
since Aug 01, 2002
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by mike hanser

thanks for the reply val, it just bugs the heck outta me that such a well quoted book should have these mistakes in it.
mike
hey,

Originally posted by Mike Kelly:
...But any changes to the reference itself do not reflect outside of the method call. But does inside the method call .


also adding to the above note, I think as soon you make changes to the reference from within the method, the original reference(the one that was passed in) becomes lost to the method, so that you cannot do any more operations on it, because the method does not know where it went :roll:

16. Variables declared in methods are not accessible from any other method. (Compiler error).
Variables declared within blocks, have the scope of the block. (loop for example)


yeah I always get confused coming from c where you can have local static variables heh...
so long,
mike
so I guess the bottom line(or one thereof...) is that any child constructor that calls a parent constructor that declares exceptions to be thrown must also throw _at least_ those same exceptions, but can throw others as well.
I was reading through chapter 11 on the Collections framework and found this error that is illustrated by an inconsistency between the venn diagram on p.328 and review question #11.11:
I think this must be a mistake--it's suggested that the Collection.addAll() method operates according to the union principle:
{1,3,2}U{1,3,2} = {1,3,2}
but evidently this is not the case as the example
shows.
If addAll() operated according to set union principle than the call to subList(2,5) on line 12 would produce IndexOutOfBoundsException.
I wonder if anyone can corroborate whether or not my assumption is correct?
just out of curiosity, does this mean thread objects with no references may be gc'ed at will?
hi anthony, thanks for the response. are you using a newer edition of Mughal than I am? (b) is given as part of the answer on p.647. hmmm maybe there's an errata somewhere for this book, will try to look it up.
hi,
can anyone shed light on a review question on threads from Mughal?
question:
==============================================
"Which of these are plausible reasons why a thread might be alive, but still not be running?"
Select all valid answers.
(a) The thread is waiting for some condition as a result of a call to wait().
(b) The thread is waiting on a monitor for an object so that it may access a certain member variable of that object.
(c) The thread is not the highest priority thread and is currently not granted CPU time.
(d) The thread is sleeping as a result of a call to the sleep() method.
==============================================
Ans: a,b,c,d
Regarding answer choice "b", it is my understanding that synchronized blocks prevent other threads from executing inside those same synchronized blocks.
Wouldn't this mean that other threads can access instance variables of an object while a thread is executing inside a synchronized block of said object?
If that is the case, wouldn that not weaken the claim made by choice "b", in other words, can it be rephrased as: "the thread does not neccessarily have to wait on a monitor for an object, it can simply access non-synchronized members at any time."
I appreciate any comments!

wierd that should be catchable by the compiler, but it compiles!
[ August 01, 2002: Message edited by: mike hanser ]