SCJP Exam Watch 7 - Object Orientation (3)

Don't be fooled by a method that's overloaded but not overridden by a subclass. It's perfectly legal to do the following:

public class Foo {
    void doStuff() {}
}

class Bar extends Foo {
    void doStuff(String s) {}
}

The Bar class has two doStuff() methods: the no-arg version it inherits from Foo (and does not override), and the overloaded doStuff(String s) defined in the Bar class. Code with a refrence to a Foo can invoke only the no-arg version. but code with a reference to a Bar can invoke either of the overloaded versions.


Refrence: SCJP Sun® Certified Programmer for Java™ 6 Study Guide Exam (310-065)

SCJP Exam Watch 6 - Object Orientation (2)

Be careful to recognize when a method is overloaded rather than overridden. You might see a method that appears to be violating a rule for overriding, but that is actually a legal overload, as follows:

public class Foo {
    public void doStuff(int y, String s) {}
    public void moreThings(int x) {}
}

class Bar extends Foo {
    public void doStuff(int y, long s) throws IOException {}
}

It's tempting to see the IOException as the problem, because the overridden doStuff() method doesn't declare an exception, and IOException is checked by the compiler.

But the doStuff() method is not overridden! Subclass Bar overloads the doStuff() method, by varying the argument list, so the IOException is fine.


Refrence: SCJP Sun® Certified Programmer for Java™ 6 Study Guide Exam (310-065)

SCJP Exam Watch 5 - Object Orientation (1)

If a method is overridden but you use a polymorphic (supertype) reference to refer to the subtype object with the overriding method, the compiler assumes you're calling the supertype version of the method.

If the supertype version declares a checked exception, but the overriding subtype method does not, the compiler still thinks you are calling a method that declares an exception.

Let's take a look at an example:

class Animal {
    public void eat() throws Exception {
        // throws an Exception
    }
}

class Dog extends Animal {
    public void eat() {
        /*no Exceptions*/
    }

    public static void main(String[] args) {
        Animal a = new Dog();
        Dog d = new Dog();
        d.eat();        // OK
        a.eat();        // Compiler error - unreported exception
    }
}

This code will not compile because of the exception declared on the Animal eat() method. This happens even though, at runtime, the eat() method used would be the Dog version, which does not declare the exception.

Refrence: SCJP Sun® Certified Programmer for Java™ 6 Study Guide Exam (310-065)

SCJP Exam Watch 4 - Encapsulation

Look out for code that appears to be asking about the behavior of a method, when the problem is actually a lack of encapsulation. Look at the following example, and see if you can figure out what's going on:

class Foo {
    public int left = 9;
    public int right = 3;

    public void setLeft(int leftNum) {
        left = leftNum;
        right = leftNum/3;
    }

    // lots of complex test code here
}

Now consider this question: Is the value of right always going to be one-third the value of left? It looks like it will, until you realize that users of the Foo class don't need to use the setLeft() method! Thay can simply go straight to the instance variables and change them to any arbitrary int value.


Refrence: SCJP Sun® Certified Programmer for Java™ 6 Study Guide Exam (310-065)

SCJP Exam Watch 3 - Array Declaration

It is never legal to include the size of the array in your declaration. Yes, we know you can do that in some other language, which is why you might see a question or two that include code similar to the following:

int[5] scores;

The preceding code won't compile. Remember, the JVM doesn't allocate space until you actually instantiate the array object. That's when size matters.


Refrence: SCJP Sun® Certified Programmer for Java™ 6 Study Guide Exam (310-065)

SCJP Exam Watch 2 - Interface Definition

Look for interface difinitions that define constants, but without explicitly using the required modifiers. For example, the following are all identical:

// Looks non-static and non-final, but isn't!
public int x = 1;
// Looks default, non-static, non-final, but isn't!
int x = 1;
// Does't show public or final
static int x = 1;
// Doesn't show public or static
final int x = 1;
// Doesn't show final
public static int x = 1;
// Doesn't show static
public final int x = 1;
// Doesn't show public 
static final int x = 1;
// What you get implicitly
public static final int x = 1;

Any combination of the required (but implicit) modifiers is legal, as is using no moddifiers at all! On the exam, you can expect to see questions you won't be able to answer correctly unless you know, for example, that an interface variable is final and can never be given a value by implementing (or any other) class.



Refrence: SCJP Sun® Certified Programmer for Java™ 6 Study Guide Exam (310-065)