This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
If I remember correctly, for Java 1.4, calling start() on a thread which had finished its run() method did not cause the exception to be thrown. The exception was only thrown if the thread could be still executing run() while start() was called a second time. That's why the statement was changed in the errata.
In Java 5.0 it appears that the exception is now thrown when calling start() on such a "dead" thread. [ January 23, 2006: Message edited by: Barry Gaunt ]
Layne, if the phrase "you'll get a big fat runtime exception" is true, why was it eliminated via the errata? I thought the errata was supposed to correct things which weren't right ?
Barry, you remember correctly, for Java 1.4, calling start() on a thread which had finished its run() method does not cause the exception to be thrown, the exception is only thrown if the thread is still executing run() while start() is called a second time.
But according to the API, this behaviour is wrong:
Now, if the thread is dead, that means it was already started, isn't it? So if the thread is dead (it's run() method has finished), then calling start() on this dead thread should throw an IllegalThreadStateException, right?
Joined: Dec 01, 2004
If start() is called more than once on a Thread object, it will throw a RuntimeException.
This is in agreement with the API. But the errata is not.
Yes. Unfortunately the reality is that some (maybe all?) Sun JDKs prior to JDK 5 did not obey the spec in this regard. Which makes this a poor test question unfortunately, though it's not the author's fault so much as tbe fault of some unknown Sun programmers(s). Anyway, the way I read the errata, "calling t.start() won't restart it" is a true statement, which is intentionally ambiguous about exactly how & why the thread won't restart. Maybe start() will throw an exception (as per the spec), or maybe start() will just return immediately with no effect (as per the buggy reality in JDK 1.4).
Errata are often written under the constraint that the replacement text cannot change the page numbering of the other text. Because the author and publisher are typically trying to just make small modifications that can go into the next printing of the book, without having to re-index the rest of the book. In this case, it would've taken somewhat more space to fully discuss the fact that the spec and implementation give contradictory results. And so I'm guessing K&B thought it was more appropriate to give a short vague-but-true answer to replace the previous answer which is specific-but-false under existing JDKs. [ February 01, 2006: Message edited by: Jim Yingst ]
We'll be posting a link to the Java 5 errata page in a few days,
Joined: Dec 01, 2004
Hi Jim, thanks for your answer. Yes I agree (always had) that the phrase "calling t.start() won't restart it" is a true statement, I was just confused about the reason the errata was striking the phrase "you'll get a big fat runtime exception", and the errata does that only for the 505 page, and not for the 536 and 508 pages.
So, if I get a question on this topic on the exam, what's the answer? is an exception thrown or not? I would be inclined to answer that with a yes. [ February 02, 2006: Message edited by: John Bran ]