These are the comments of a greenhorn who, as I said in an earlier post, was disappointed by his passing score on the professional exam. So I might be corrected and instructed by people who know a lot more than me, and indeed I would be eager to hear it.
What I found is that the
test often seemed to find a way to ask me something I had never encountered in the
Java Tutorials and instruction -- the "corner case" is the term, right? The Java Tutorials and even the exam preparatory course instruct you on What Things Are And How They Usually Work. I am perfectly capable of talking all day long about the various technologies covered in the exam, the distinction between the various RowSet subinterfaces, the tricks of regex, or that consoleInstance.readPassword() returns a char[] and not a
String, etc.... but the test often pushes you and throws things at you that are just... a little... different. Overall I thought it was an excellent exam that truly puts you through the paces -- in other words, not exactly like just buying a piece of paper online!
Here are some easy things that are worth a few questions, and that are worth looking at FIRST in a question before you starting grinding through the code line by line: Always make sure that objects created in try-with-resources blocks (especially classes defined in the question) implement AutoCloseable. Always make sure that one of your references assigned in a try-with resources declaration are not reassigned in the try block -- they are implicitly final. Always check multicatch clauses to make sure the exceptions are not related, and always make sure the exception is not being reassigned in the catch block (implicitly final again). These are easy compiler errors. Always make sure that the classes in a TreeSet<T> can be compared, and remember that it's not a compiler error, but a RUNTIME error if the class doesn't -- and that's only is when the SECOND object is added! Make sure that threadInstance.start() is actually invoked, as opposed to just .run(). Make sure that a class extending
Thread (as opposed to implementing Runnable) properly overrides .run() and does not just overload it, e.g. run(parameter), since that means the default .run() of the Thread executes with no output. And so forth.
And then, in the class design, advanced class design and interface stuff -- in practice, write your own code, try to break your code every way from Sunday, especially on access modifiers. Try to break it by overriding static methods with instance methods and vice versa. See what can be overridden and shadowed and what can't... create classes and nested classes with the same name, using methods with the same name... also I got caught by some interface questions that you don't often encounter, for example, the use of fields in the interface, which are implicitly static and final -- constants, in other words. What happens when an interface has such a field, e.g., String type = "string"; and then the implementing class tries to reassign it? Nope. But what happens when the implementing class SHADOWS that declaration with it's own "String type = "otherString". I will confess to you that, what I think I remember doing is, I think I thought automatically, "Reassigning field defined in interface, can't be done, compiler error." But it was shadowed... ugh.
Whew! Just in time for Java 8.
