Hi Darren,
My situation is similar to yours. As the saying goes, I don't just feel your pain, I
feel your pain. Back in October my job was "eliminated", along with the jobs of several hundred other highly experienced software engineers, architects, and project managers. I have about 11 years developing server side software in
Java, 5 years before that working in C, C++, and Unix shell scripting, and have a long track record of accomplishments and successes to my name. Shortly after the axe fell, I decided to use some of my suddenly ample free time to prepare for the SCJP test that I'd never been able to get around to while I was working full time.
Initially, I thought that a fairly casual brushing up of my knowledge of basic Java SE would be enough for me to do well on the real exam, but the difficulty of passing, much less getting a high score on the mock exams, soon humbled me. My first mock exam scores left me bruised and frustrated, but determined to press on. Like you, my days now revolve around working through the K&B book yet another time, reading and rereading chapters of Mughal and Rasmussens's Programmer's Guide to the SCJP, and getting beat up by the Enthuware mock exam software, and by the truly brutal OCP Java SE 6 Programmer Practice Exams book by Bert Bates and Kathy Sierra. To supplement all that, I've spent a lot of time with the API javadocs, the Java Language specs, and also Oaks and Wong's Java Threads, Third Edition, and Naftalin and Wadler's Java Generics and Collections. On top of that, I've written many, many small programs to test and improve my understanding. Based on my recent mock exam scores, ranging from the high 80s to the mid 90s, all this work finally seems to be paying off... Of course, I won't know for sure until I take the actual OCPJP 6 exam, which I plan to do next week.
It seems to me that you are already doing what you need to do to prepare for the certification exam. One thing that I've learned from taking the mock exams that has helped me do better on them is that there are two basic ways that I can miss a question. First, I just don't know the answer. For that, the remedy is more studying and coding. Second, I fall for one of the misdirection traps designed to divert my attention away from the right answer that I do know, but don't see. For that, you need to analyze the wording of the questions that fooled you, make note of the deceptive
patterns, and then take more mock exams armed with greater awareness of potential traps.
Just as one example of what I'm talking about, I recently missed a question where a List was loaded with superclass references to instances of the superclass itself and of subclasses, all of which had static methods with the same signatures. Then, the list was run through a foreach loop. Immediately, I thought that the output would be from the superclass version of the method, knowing that static methods cannot be overridden, and
thinking that each iteration of the loop was invoking the superclass static method through a superclass reference. What I missed was that the actual method call was to the static method of the subclass that contained the main method being executed, like this:
My misbehaving brain rendered this as:
It's kind of like that old visual perception trick where "Paris in the the spring" is printed in a triangle and almost everyone who hasn't seen it before sees "Paris in the spring." The good news is that now that I'm aware of this particular mean trick, I probably won't fall for it if it comes up in the real exam. The bad news is that this is just one of the many mean tricks that the test designers have up their sleeves. So all you can do is take a lot of mock exams, learn as many of the misdirection patterns as you can, and try really hard to read the question that is there instead of the question that is not there that the wording intentionally misleads you to see.
I hope this helps, and please wish me luck, as I wish you,
Regards,
Frank
1
. I'm used to Eclipse or RAD taking care of all that stuff and concentrating on getting the business requirements right instead of trying to be a human compiler. But, I guess that's what you have to put up with to pass the test... As far as the rule that you mentioned goes, that "you can't have a static methods in an abstract class", that's actually not the case. Here's an example that compiles and runs, showing that an abstract class can have a static method:
