I don't have much time right now, but I'll try to elaborate some more on the points I described.
About the "word" questions, I'll let you know what I would have spent more time on (and why) if I were to take the test over again.
Collection Framework: It's not good enough to know which concrete collection class type to use. It's ok given a scenario like ...
Q:"Which collection class is best suited when you want to keep track of a list of types of german beer in alphabetical order"
A:"TreeSet" - "Tree" for the alphabetical (natural order) part of the description, and "Set" for the uniqueness implied by the word "types" above.
... more subtly, What would be the answer if the question were...
"Which Collection type is best suited when you want to keep track of a list of types of german beer in alphabetical order".
...In this question, collection was turned into Collection [upper case], and the word class was removed. Now the question is asking which interface, inheriting from Collection, is best suited for...". A subtle difference, but don't fall for it. In this last case the answer could be "Set" or "SortedSet" depending on which choices are available. There are a myriad of different subtle scenarios like this. "K & B" points out all the "triggers" you would need to catch this in Chapter 7, I would have spent more time here.
Threads: It is soooo very important to understand what state changes a
thread makes depending upon different events such as ...
- A call to join().
- A call to wait().
- An overloaded wait() call times out on an object.
- when the lock on the object has already been released.
- when the lock on the object is still held.
- Many many more scenarios change thread state.
I would have spent more time constructing state flow diagrams for the different scenarios.
I've gotta go, I'll answer more later.
[Some time later]
TRIGGERS:
While taking mock exams, I found that I would miss many "example code" questions not because I didn't understand the material, but because I had glossed over an easy-to-miss syntax or logic error. I called them "stupid" errors [stupid on my part, absolutely not on the part of the exam makers]. I realized that I would probably fall for the same error more than once if I just told myself "Don't do that again!". I decided to construct a list of reminders in code form (triggers) to remind me to look for the ever present TRICK.
What I mean by trigger is: A small identifiable piece of code that instinctively makes you look for a trick (like Pavlov's dog). By writing down a list of code items, and associated tricks to look out for, you have the opportunity to focus on your weaknesses in nice bite sized chunks.
This is just an approach that worked for me, and everyone is different, so your approach might be different as well. If you haven't formulated an approach to these "stupid" errors, then you might want to try this one on for size.
Here are a few of the triggers and associated Tricks I used to help me for the exam (in every case, I missed a mock exam question due to the same stupid error that I eventually got correct on the real thing).
- wait(), join(), sleep() : Look for try/catch block to catch InterruptedException.
- case: x : Look for x as non-final variable... Compiler error.
- [top level class] : Look for any other access modifier besides public and [default access]... Compiler error.
- [anonymous, method-local, inner class] : Look for semi-colon at closing bracket. If not there... Compiler error.
- ["final" base class method] : Look for shadowing in child method, access from child method.
- [Wrapper Class].[Any Method] : SUPER CLOSE SCRUTINY! could be NFE Error, incorrect return type.
If you attempt to follow this approach it is important to know the material, and read books before you attempt to make a list, otherwise your list will be cumbersome.
I hope this helps,
Doug
[ June 17, 2003: Message edited by: Doug Newcomb ]
[ June 17, 2003: Message edited by: Doug Newcomb ]
[ June 18, 2003: Message edited by: Doug Newcomb ]