Java Practice Test - 7

default access is the package oriented access modifier.
Option 1 and 3 are wrong because public and protected are less restrictive. Option 2 and 4 are wrong because abstract and synchronized are not access modifiers.

2 is correct because multiple threads are allowed to enter nonsynchronized code, even within a class that has some synchronized methods.
1 is incorrect because static methods can be synchronized; they synchronize on the lock on the instance of class java.lang. The class that represents the class type.
3 is incorrect because only methods—not variables—can be marked synchronized.
4 is incorrect because a sleeping thread still maintains its locks.

This is a great way to think about when objects can be garbage collected.
Option A and B assume guarantees that the garbage collector never makes.
Option D is wrong because of the now famous islands of isolation scenario.

When running the program you entered 3 arguments "red", "green" and "blue". When dealing with arrays in java you must remember ALL ARRAYS IN JAVA ARE ZERO BASED therefore args[0] becomes "red", args[1] becomes "green" and args[2] becomes "blue".
When the program entcounters line 8 above at runtime it looks for args[3] which has never been created therefore you get an
ArrayIndexOutOfBoundsException at runtime.

The thread MyThread will start and loop three times (from 0 to 2).
Option A is incorrect because the Thread class implements the Runnable interface; therefore, in line 7, Thread can take an object of type Thread as an argument in the constructor.
Option B and C are incorrect because the variable i in the for loop starts with a value of 0 and ends with a value of 2.

Option A is correct. Because assertions may be disabled, programs must not assume that the boolean expressions contained in assertions will be evaluated. Thus these expressions should be free of side effects. That is, evaluating such an expression should not affect any state that is visible after the evaluation is complete. Although it is not illegal for a boolean expression contained in an assertion to have a side effect, it is generally inappropriate, as it could cause program behaviour to vary depending on whether assertions are enabled or disabled.
Assertion checking may be disabled for increased performance. Typically, assertion checking is enabled during program development and testing and disabled for deployment.
Option B is wrong. Because you assert that something is "true". True is Boolean. So, an expression must evaluate to Boolean, not int or byte or anything else. Use the same rules for an assertion expression that you would use for a while condition.
Option C is wrong. Usually, enforcing a precondition on a public method is done by condition-checking code that you write yourself, to give you specific exceptions.
Option D is wrong. "You're never supposed to handle an assertion failure"
Not all legal uses of assertions are considered appropriate. As with so much of Java, you can abuse the intended use for assertions, despite the best efforts of Sun's Java engineers to discourage you. For example, you're never supposed to handle an assertion failure. That means don't catch it with a catch clause and attempt to recover. Legally, however, AssertionError is a subclass of Throwable, so it can be caught. But just don't do it! If you're going to try to recover from something, it should be an exception. To discourage you from trying to substitute an assertion for an exception, theAssertionError doesn't provide access to the object that generated it. All you get is the String message.

The prefix and postfix unary operators have a higher order of evaluation than the relational operators. So on line 4 the variable i is incremented and the variable j is decremented before the greater than comparison is made. As the loop executes the comparison on line 4 will be:
if(i > j)
if(2 > 9)
if(3 > 8)
if(4 > 7)
if(5 > 6) at this point i is not less than 5, therefore the loop terminates and line 9 outputs the values of i and j as 5 and 6 respectively.
The continue statement never gets to execute because i never reaches a value that is greater than j.

The only two real contenders are C and D. Protected access Option C makes a member accessible only to classes in the same package or subclass of the class. While default access Option D makes a member accessible only to classes in the same package.

Switch statements are based on integer expressions and since both bytes and chars can implicitly be widened to an integer, these can also be used. Also short data types can be used. Short and Long are wrapper classes and reference types can not be used as variables.

(A) is valid interface declarations.
(B) and (C) are incorrect because interface variables cannot be either protected ortransient. (D) is incorrect because interface methods cannot be final or static.

Even though o and oc are reference variables of different types, they are both referring to the same object. This means that == will resolve to true and that the defaultequals() method will also resolve to true.

In Java, String.equals(Object) works correctly because String's equals method overrides Object.equals to handle String comparison. Both s.equals(o) and o.equals(s) return true because they reference the same String object 'foo'. The equals method checks for actual content equality, not reference equality.

Can you guarantee the order in which threads are going to run? No you can't. So how do you know what the output will be? The output cannot be determined.

The lines to watch here are lines 9 & 10. Line 9 features the non-shortcut version of theOR operator so both of its operands will be evaluated and therefore methodB(4) is executed.
However line 10 has the shortcut version of the OR operator and if the 1st of its operands evaluates to true (which in this case is true), then the 2nd operand isn't evaluated, so methodB(8) never gets called.
The loop is only executed once, b is initialized to false and is assigned true on line 9. Thus j = 4.

All of the collection classes allow you to grow or shrink the size of your collection.ArrayList provides an index to its elements. The newer collection classes tend not to have synchronized methods. Vector is an older implementation of ArrayListfunctionality and has synchronized methods; it is slower than ArrayList.

Option A is correct. notify() - wakes up a single thread that is waiting on this object's monitor.
Option B is wrong. wait() causes the current thread to wait until another thread invokes the notify() method or the notifyAll() method for this object.
Option C is wrong. Methods of the InputStream class block until input data is available, the end of the stream is detected, or an exception is thrown. Blocking means that a thread may stop until certain conditions are met.
Option D is wrong. sleep() - Causes the currently executing thread to sleep (temporarily cease execution) for a specified number of milliseconds. The thread does not lose ownership of any monitors.

Case expressions must be constant expressions. Since x is marked final, lines 12 and 13 are legal; however y is not a final so the compiler will fail at line 11.

Option B is correct. If an object can be accessed from a live thread, it can't be garbage collected.
Option A is wrong. Runtime.gc() asks the garbage collector to run, but the garbage collector never makes any guarantees about when it will run or what unreachable objects it will free from memory.
Option C is wrong. The garbage collector runs immediately the system is out of memory before an OutOfMemoryException is thrown by the JVM.
Option D is wrong. If this were the case then the garbage collector would actively hang onto objects until a program finishes - this goes against the purpose of the garbage collector.

Option B is correct - The notify method only wakes the thread. It does not guarantee that the thread will run.
Option A is incorrect - just because another thread activates the modify method in A this does not mean that the thread will automatically resume execution
Option C is incorrect - This is incorrect because as said in Answer B notify only wakes the thread but further to this once it is awake it goes back into the stack and awaits execution therefore it is not a "direct and sole consequence of the notify call"
Option D is incorrect - The notify method wakes one waiting thread up. If there are more than one sleeping threads then the choice as to which thread to wake is made by the machine rather than you therefore you cannot guarantee that the notify'ed thread will be the first waiting thread.

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.

An assertion Error is thrown as normal giving the output "assertion failed". The word "finished" is not printed (ensure you run with the -ea option)
Assertion failures are generally labeled in the stack trace with the file and line number from which they were thrown, and also in this case with the error's detail message "assertion failed". The detail message is supplied by the assert statement in line 6.

When z == 0 , case x-2 is matched. When z == 1, case x-1 is matched and then the break occurs. When z == 2, case x, then default, then x-1 are all matched. When z == 3, default, then x-1 are matched. The rules for default are that it will fall through from above like any other case (for instance when z == 2), and that it will match when no other cases match (for instance when z==3).

Option B is correct because to set the value of a String variable to null you must use "null" and not "NULL".

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 casex-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.

Can you guarantee the order in which threads are going to run? No you can't. So how do you know what the output will be? The output cannot be determined.
add this code after line 28:
try { Thread.sleep(5000); } catch(InterruptedException e) { }
and you have some chance of predicting the outcome.