What will be the output of the program?

interface Count 
{
    short counter = 0;
    void countUp();
}
public class TestCount implements Count 
{
    public static void main(String [] args) 
    {
        TestCount t = new TestCount();
        t.countUp();
    }
    public void countUp() 
    {
        for (int x = 6; x>counter; x--, ++counter) /* Line 14 */
        {
            System.out.print(" " + counter);
        }
    }
}

(1) and (3) are integer literals (32 bits), and integers can be legally assigned to floats (also 32 bits). (6) is correct because (F) is appended to the literal, declaring it as a float rather than a double (the default for floating point literals).

(2), (4),and (5) are all doubles.

Option A is correct. If the class specified in the catch clause does have subclasses, any exception object that subclasses the specified class will be caught as well.

Option B is wrong. The error class is a subclass of Throwable and not Runtime Exception.

Option C is wrong. You do not catch this class of error.

Option D is wrong. An exception can be thrown to the next method higher up the call stack.

Nonnested classes cannot be marked protected (or final for that matter), so the compiler will fail at protected class NewTreeSet.

Line 3 uses an assignment as opposed to comparison. Because of this, the if statement receives an integer value instead of a boolean. And so the compilation fails.

This code is an example of an anonymous inner class. They can be declared to extend another class or implement a single interface. Since they have no name you can not use the "new" keyword on them.

In this case the annoynous class is extending the Object class. Within the {} you place the methods you want for that class. After this class has been declared its methods can be used by that object in the usual way e.g. objectname.annoymousClassMethod()

Option D is correct because synchronizing the code that actually does the increase will protect the code from being accessed by more than one thread at a time.

Option A is incorrect because synchronizing the run() method would stop other threads from running the run() method (a bad idea) but still would not prevent other threads with other runnables from accessing the increase() method.

Option B is incorrect for virtually the same reason as A?synchronizing the code that calls the increase() method does not prevent other code from calling the increase() method.

default access is the "package oriented" access modifier.

Option A and C are wrong because public and protected are less restrictive. Option B and D are wrong because abstract and synchronized are not access modifiers.

Option C is true because multiple VM flags can be used on a single invocation of a Java program.

Option A is incorrect because at runtime assertions are ignored by default.

Option B is incorrect because as of Java 1.4 you must add the argument -source 1.4 to the command line if you want the compiler to compile assertion statements.

Option D is incorrect because the VM evaluates all assertion flags left to right.

The case expressions are all legal because x is marked final, which means the expressions can be evaluated at compile time. In the first iteration of the for loop case x-2 matches, so 2 is printed. In the second iteration, x-1 is matched so 1 and 2 are printed (remember, once a match is found all remaining statements are executed until a break statement is encountered). In the third iteration, x is matched. So 0 1 and 2 are printed.

Option A is correct. A public access modifier is acceptable. The method prototypes in an interface are all abstract by virtue of their declaration, and should not be declared abstract.

Option B is wrong. The final modifier means that this method cannot be constructed in a subclass. A final method cannot be abstract.

Option C is wrong. static is concerned with the class and not an instance.

Option D is wrong. protected is not permitted when declaring a method of an interface. See information below.

Member declarations in an interface disallow the use of some declaration modifiers; you cannot use transient, volatile, or synchronized in a member declaration in an interface. Also, you may not use the private and protected specifiers when declaring members of an interface.