File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Kathy's Book----A Book written in Hurry? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Kathy Watch "Kathy New topic

Kathy's Book----A Book written in Hurry?

Sarma Lolla
Ranch Hand

Joined: Oct 21, 2002
Posts: 203
If any one goes through the errata it already mentions about 50 pages where you need to change at least a line.
Here are more....
What is integer range?
-2147483648 To 2147483647 But on page 12 it is mentioned as 2147483467
No mention about % operator on negative numbers.
Why the examples in chapter 3 are on AWT when AWT is not in syllabus? Are they picked up from previous version of the book?
On page 177---
float a= 100.001 //Isn't this error?
int b= (int)a;//Explicit cast....
More to come.....
[ March 05, 2003: Message edited by: Sarma Lolla ]
Kathy Sierra
Cowgirl and Author

Joined: Oct 10, 2002
Posts: 1589
Howdy -
First of all, I must say that your comments are taken very seriously and we're doing everything we can to make corrections (more about HOW we're doing that at the bottom).
There are WAY more errata than we ever imagined could happen. We had never been through this process, and we did a terrible job at checking the final edits. We did not understand the stages that the book went through at the end, and we were not able to work on pages that matched the final output of the book. We also put too much trust in the paid tech editors and copy editors, and we also trusted that our final corrections would indeed show up in the printed book.
Well, we learned a hard lesson, and in the end, it was our responsibility and we should have paid much more attention.
So, we deeply apologize and anyone who feels the book is doing more harm than good for them should return it for a refund!
I will tell you how we are addressing the issues:
* we have submitted the errata to the publisher for the second and third printings. The second printing is already in progress, so the next version out will have the vast majority of the corrections made. Assuming the publisher implements the errata correctly -- we have no control over that and we do not get to see the corrected pages, but it should make a big difference.
* we are changing the way the errata pages are displayed so that only the technical inaccuracies that are significant in your ability to take the exam will be put in the high-priority errata list. That way, you don't have to sift through dozens of references to things like "extra white space in the margin" or "misspelled the word 'the'" and can concentrate on just the serious ones.
* we do believe that while the errata is MUCH too large, the vast majority are NOT things that would affect your ability on the exam, assuming you do know Java going in. In other words, if a curly brace is cut off from the end of a code-listing, or a line number in an error message is off (usually because when the code gets formatted in the book it may have fewer blank lines than the original source code had), we believe these are very annoying but shouldn't create serious problems for a Java programmer. They're still bad, and we're doing everything to correct these in the book, but they won't hurt you.
* we do know that, because the mock exams were reviewed by a team here on javaranch (and a very AMAZING team), the mock exams are very nearly error-free, and we consider that to be the most important factor in preparing for the exam.
We are also dramatically changing the process for our next book, which is from O'Reilly, in that book WE have control of the pages, completely, all the way through. They go from our hands, untouched, directly to the printer. That's a HUGE change in the process, and this way there is no chance that errors can be introduced in the final stages of copy editing, or that -- for example -- non-final draft pages can end up in the final book. Of course, we'll have nobody but ourselves to blame for errors in THAT book
Again, we do deeply apologize, and thank everyone who has been so helpful in submitting errata; most of it will show up in the second printing coming out very soon.
When I was studying for the exam in 1997, I was extremely critical and harsh on the books I used that had a lot of errors and swore I would never let that happen.
Yet, it did, and we don't even have a good excuse except that we just did not pay attention the way we should have, and we took too much for granted. In the end, it is our fault, and we can only do our best to correct it as soon as we can.
But despite the errors, the book *is* helping a lot of people get through the exam in what we believe is the least painful way, and for that, we're grateful. For many people, the majority of the errors did not affect their studies. But for those who are bothered by it, they should return the book and get one of the other good ones instead. I recommend both RHE and Mughall, as do many others on javaranch. It was the RHE book that got *me* through the exam in the end, even though they had an errata in their second edition that was even longer than ours... (hard to believe, I know And of course, I'm allowed to tease them about it because I know all of them, and Simon is a dear friend of ours).
We do use a few AWT examples because they are used on the real exam. This is a point of confusion for a lot of people. When they see AWT code on the exam, they wonder why, since it is no longer in the objectives, but the exam code examples are free to use anything, as long as the question doesn't require actual knowledge of that API. For example, a question about package statements or declarations might use AWT as part of the code, but without requiring knowledge of AWT in order to answer the question. When you see code like that on the real exam, you *know* the question is about some fundamental Java issue, so just look for language problems, syntax errors, etc. A private top-level class is wrong regardless of whether it's using GUI code. Or a final instance variable that's never initialized would be wrong even if it's in a class with I/O code. Your knowledge (or lack) of I/O does not affect your ability to process the code example and look for problems.
Nearly all of the weird examples we use are in there because that's what's in the exam. So you might not like it, but at least you won't be surprised in the real thing.
Anyway, your comments are extremely important and we're taking all of it very seriously, and have been paying very close attention to the errata we have been sent by readers.
We will let you all know when we've finished reorganizing the errata to make it much easier (and much smaller to deal with.
(and Bert agrees with me completely, except he wants you all to know that he is SURE that most of the errata comes from the pages *I* did
Sarma Lolla
Ranch Hand

Joined: Oct 21, 2002
Posts: 203
Thanks for responding with such a long answer. It is unfortunate to see this good book facing these problems. Hope fully every thing will be alright from 3rd print onwards...
It is sorta covered in the JavaRanch Style Guide.
subject: Kathy's Book----A Book written in Hurry?
It's not a secret anymore!