Java Advanced Practice Test - Threads, Assertions, and Collections

(1) is wrong. 3/2 = 1 (integer arithmetic).
(2) is wrong. 3 < 2 = false.
(3) is correct. 3 * 4 = 12.
(4) is correct. 3 <<2= 12. In binary 3 is 11, now shift the bits two places to the left and we get 1100 which is 12 in binary (322).

Yes, always the elements in the collection are ordered.

The switch statement can only be supported by integers or variables more "narrow" than an integer i.e. byte, char, short. Here a Float wrapper object is used and so the compilation fails.

Option C is suitable to start a thread.

Option B is correct because a method-local inner class can be abstract, although it means a subclass of the inner class must be created if the abstract class is to be used (so an abstract method-local inner class is probably not useful).
Option A is incorrect because a method-local inner class does not have to be declaredfinal (although it is legal to do so).
C and D are incorrect because a method-local inner class cannot be made public(remember-you cannot mark any local variables as public), or static.

When the start() method is attempted a second time on a single Thread object, the method will throw an IllegalThreadStateException (you will not need to know this exception name for the exam). Even if the thread has finished running, it is still illegal to call start() again.

Adding an assertion statement to a switch statement that previously had no default case is considered an excellent use of the assert mechanism.
Option A is incorrect because only Java expressions that return a value can be used. For instance, a method that returns void is illegal.
Option C is incorrect because the expression after the colon must have a value.
Option D is incorrect because assertions throw errors and not exceptions, and assertion errors do cause program termination and should not be handled.

Option C is correct. The output is "ELSE". Only when a is false do the output lines after 11 get some chance of executing.
Option A is wrong. The output is "A". When a is true, irrespective of the value of b, only the line 5 output will be executed. The condition at line 7 will never be evaluated (when a is true it will always be trapped by the line 12 condition) therefore the output will never be "A && B".
Option B is wrong. The output is "A". When a is true, irrespective of the value of b, only the line 5 output will be executed.
Option D is wrong. The output is "notB".

If a Runnable object is passed to the Thread constructor, then the run method of theThread class will invoke the run method of the Runnable object.
In this case, however, the run method in the Thread class is overridden by the run method in MyThread class. Therefore the run() method in MyRunnable is never invoked.
Both times, the run() method in MyThread is invoked instead.

The program will execute without any problems and print 12 12 12 12.

This is what happens:
(1) The execution of the try block (line 5) completes abruptly because of the throwstatement (line 7).
(2) The exception cannot be assigned to the parameter of any catch clause of the trystatement therefore the finally block is executed (line 9) and "finally" is output (line 11).
(3) The finally block completes normally, and then the try statement completes abruptly because of the throw statement (line 7).
(4) The exception is propagated up the call stack and is caught by the catch in the main method (line 20). This prints "exception".
(5) Lastly program execution continues, because the exception has been caught, and "finished" is output (line 24).

Option C will not compile; the synchronized modifier applies only to methods.
Option A and B will compile because protected and transient are legal variable modifiers. Option D will compile because volatile is a proper variable modifier.

The foo() method returns void. It is a perfectly acceptable method, but because it returns void it cannot be used in an assert statement, so line 18 will not compile.

Option D is correct. Compilation fails because of an unreachable statement at line 14. It is a compile-time error if a statement cannot be executed because it is unreachable. The question is now, why is line 20 unreachable? If it is because of the assert then surely line 6 would also be unreachable. The answer must be something other than assert.
Examine the following:
A while statement can complete normally if and only if at least one of the following is true:

• The while statement is reachable and the condition expression is not a constant expression with value true.
  -There is a reachable break statement that exits the while statement.
  The while statement at line 11 is infinite and there is no break statement therefore line 14 is unreachable. You can test this with the following code:
  public class Test80
  {
      public void foo()
      {
          assert false;
          assert false;
      }
      public void bar()
      {
          while(true)
          {
              assert false;
              break;
          }
          assert false; 
      }
  }

Assert statements should not cause side effects. Line 22 changes the value of z if the assert statement is false.
Option A is fine; a second expression in an assert statement is not required.
Option B is fine because it is perfectly acceptable to call a method with the second expression of an assert statement.
Option C is fine because it is proper to call an assert statement conditionally.

Option B is correct. Class B inherits Class A's constructor which has no arguments.
Option A is wrong. Class B inherits Class A's constructor which uses default access.
Option C is wrong. There is just no implicit call to this( ).

Option A is correct. When you create an array (f1 = new float[10];) the elements are initialises to the default values for the primitive data type (float in this case - 0.0), sof1 will contain 10 elements each with a value of 0.0. f2 has been declared but has not been initialised, it has the ability to reference or point to an array but as yet does not point to any array. f2 = f1; copies the reference (pointer/memory address) of f1 intof2 so now f2 points at the array pointed to by f1.
This means that the values returned by f2 are the values returned by f1. Changes to f1are also changes to f2 because both f1 and f2 point to the same array.

b1 is a Boolean object with value false. b2 gets b1's primitive value (false). The !b2 condition is true (NOT false = true), so b2 becomes true and "x" prints. Line 13: b1 & b2 uses Boolean objects. In JDK 1.6+, Boolean objects can use & operator with unboxing. b1 unboxes to false, b2 is true. false & true = false, so the if block doesn't execute. Finally "z" prints. Output: "x z".

All of this code is legal, and line 8 creates a new String with a value of "42.5". Lines 9 and 10 convert the String to a double and then back again. Line 11 is fun—Math.ceil()'s argument expression is evaluated first. We invoke the valueOf()method that returns an anonymous Double object (with a value of 42.5). Then thedoubleValue() method is called (invoked on the newly created Double object), and returns a double primitive (there and back again), with a value of (you guessed it) 42.5. The ceil() method converts this to 43.0, which is cast to an int and assigned to x.

In the fix() method, the reference variable tt refers to the same object (class Two) as the t reference variable. Updating tt.x in the fix() method updates t.x (they are one in the same object). Remember also that the instance variable x in the Two class is initialized to 0.

A string is immutable, it cannot be changed, that's the reason for the StringBufferclass. The stringReplace method does not change the string declared on line 14, so this remains set to "java".
Method parameters are always passed by value - a copy is passed into the method - if the copy changes, the original remains intact, line 5 changes the reference i.e. text points to a new String object, however this is lost when the method completes. ThetextBuffer is a StringBuffer so it can be changed.
This change is carried out on line 9, so "java" becomes "javac", the text reference on line 9 remains unchanged. This gives us the output of "javajavac"

(2) and (5). TreeMap is the only class that must be imported. TreeSet does not need an import statement because it is described with a fully qualified name.
(1) is incorrect because TreeMap must be imported. (3) is incorrect syntax for an import statement. (4) is incorrect because it will not import TreeMap, which is required.

Compilation fails because the argument and the condition of while loop must be of primitive type boolean. In Java, one does not represent the true state of a boolean, it is rather seen as an integer.

In Java, boolean instance variables are initialized to false, so the if test on line 7 is true and hand is incremented. Line 9 is legal syntax, a do nothing statement. The else-if is true so hand has 7 added to it and is then incremented.

As instance variables, b1 and b2 are initialized to false. The if tests on lines 7 and 9 are successful so b1 is set to true and x is incremented. The next if test to succeed is on line 19 (note that the code is not testing to see if b2 is true, it is setting b2 to be true). Since line 19 was successful, subsequent else-if's (line 21) will be skipped.