Mark Lau

Ranch Hand
+ Follow
since Dec 15, 2001
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mark Lau

OK, OK, I gotcha. I was suspecting, though.
So javacertificate is actually right, right?
I think that we can also directly invoke the run method of the thread like so:;
After all, the start method also simply calls run(), right?
But look at this. This problem is from

Which of the following statements are true? [Check all correct answers]
1 A thread is a different program.
2 A thread can share data with other threads.
3 A thread is started by calling the start method.
4 A thread is started by calling the run method.

javacertificate says only 2 and 3 are correct. I think 2 and 3 and 4 are all correct.
This is what says:

The only correct way to start a thread is calling the start method of the Thread class.

Do you people agree?
I took the exam this morning. The problems are difficult. You have to be careful about the command options.
The book I used is LPIC1 certification bible by Nash & Nash. It is not good!
1. It does not have a real hardware section, whereas I had 7 questions about hardware. Well, the book does have a hardware section, but it only talks about minimum hard ware requirement to install linux.
2. The mock exams that come with the book serverely misled me. They do not reflect the level difficulty of the real exam and the style of the mock exam problems do not match those of the real exam.
3. The book never mentions anything about journalling file system.
Any good book to recommend? I have ordered O'Reilly's LPIC in a Nutshell. Dont' know if is good. Please share with us your LPIC experiences.
[ September 09, 2003: Message edited by: Gene Chao ]
17 years ago
Hey, Bert, good to see you here. So that will appear in your next erratum?
On Page 238 of Sierra and Bates, they say

A finally block encloses code that is always executed at some point after the try block, whether an exception was thrown or not. Even if there is a return statement in the try block, the finally block executes right after the return statement! (Boldened by G. Chao)

And the following code is from Question 15 of Marcus Green at , (Line number added by G. Chao)

If the file "Hello.txt" does not exist, we get this output:
No such file found, doing finally, -1
If we comment out Line 13, the output will be:
No such file found, doing finally, 0
Both cases show that the finally block executes before the return statement, not after it.
If we comment out both return statements and put a return statement right in the try block like so:

then the code won't compile at all, the compiler would say that we are missing a return statement.
So, are Sierra and Bates wrong?
Anupam, I don't think your understanding of b.wait() is right. Earnest is right and I am probably right, too.
I think I can prove this. Please read.
Run the following code:

And the printout will be Total is 0. This is because the main of ThreadA does not wait until ThreadB finishes.
Run the following code and you'll get Total is 5050.

And this is because b.join() forces the main of ThreadA to wait until b finishes its job.
Run the following code, and you'll also get what you expect: Total is 5050

And this is because you put the main of ThreadA to sleep for 5 seconds,and during this time, b has finished its job.
Interesting, isn't it?
So, what's the difference between wait() and join()?
[ September 05, 2003: Message edited by: Gene Chao ]
OK, here is the full code.

Sorry, but b.wait() means that the CALLER (here, a) should wait until someone calls b.notify(). You don't show the code for b, but presumably the run() method in the ThreadB class calls notify() -- otherwise "a" would wait forever.
The object you call wait() on is used as a kind of "message board;" the word people usually use is "monitor."

So ThreadA is actually saying, Little b, go ahead and finish your job, I'll be here waiting until get notified.
But then, join() also works like this, the only difference is that you don't wait for any notification. So please explain any other differences between wait() and join().
Thanks a lot.
[ September 05, 2003: Message edited by: Gene Chao ]

I am afraid not. b.wait() means the thread b is waiting.

Then would you please explain Line 7 and Line 8? Thanks.

You can use the join() method in case you wish that thread threadA should wait for thread b to finish its work and then intimate thread threadA when done.

Yes, this I understand
It seems that my understanding of the wait() method is contrary to what it really is.
It looks like when ThreadA calls b.wait(), ThreadA is really saying, "little b, go ahead and finish your job, I will be here waiting for you. Let me know when you are done.".
Is this right?
[ September 05, 2003: Message edited by: Gene Chao ]
I don't think that I am ever clear about Thread synchronization.
A code snippet from Page 529 of Sierra and Bates:

I am really confused about line 7 and 8.
In line 7, the main method says that it is "Waiting for b to complete", and then in line 8, the main method says

So, who the heck is waiting? The main or b? Line 8 seems to be saying "Let b wait" and this conflicts with what the main says in Line 7.
Please shed some light on me. Thanks.
[ September 05, 2003: Message edited by: Gene Chao ]
Thank you, Uma.
That means Unni was not right when s/he said that it is absoloutely fine to create an anonymous inner class like
Boo f = new Boo(String s) {};

It is absoloutely fine to create an anonymous inner class the way you mentioned above.

One more thing about the line of code above. You say that it is fine. But I don't really remember of any anonymous inner class constructor to which is passed an argument like this. Since in an anonymous inner class, we are really only supposed to override or implement a method, what and how are we going to use the argument String s?

"String s; " is just a (re-declared) member variable in the new anonymous inner class. Anything between the curly brackets are class definitions - you can have member variables, methods..... inside them.

OK, thank. So in this particular case, we only declare String s; in the inner class and we don't really do anything about s, right?
This is about problem 4 on page 482 of Sierra and Bates:
4. Given the following,

which two create an anonymous inner class from within class Bar? (Choose two.)
A. Boo f = new Boo(24) {};
B. Boo f = new Bar() {};
C. Boo f = new Boo() { String s;};
D. Bar f = new Boo(String s) {};
E. Boo f = new Boo.Bar(String s) {};
The answer given in that book is B & C.
I don't understand why C is right. { String S; } simply does not make sense to me. Could you please explain the plain declaration String s; to me? What is it trying to do in that curly braces?
Besides, will the following line create an anonymous inner class from within class Bar as shown above?

If not, why?
Thank you.
[ September 04, 2003: Message edited by: Gene Chao ]
We know that the following compiles fine.

Now, right below line 2, I instantiate an Outer and try to use it inside doStuff() like so:
Outer outer = new Outer(); // 3
System.out.println("outer instance reference is: " + outer.this); // 4.
Line 4 won't compile, javac says that it cannot resolve the symbol outer. If we modify Line 4 by removing ".this" like
System.out.println("outer instance reference is: " + outer);
then it compiles and runs OK.
So, does this mean that we can only do OuterClassName.this, but not outerClassInstance.this in the inner class? Or does outerClassInstance.this in an inner class not make sense?
Thanks a lot