1. Can an abstract method be overridden?
Answer: Yes. Because an abstract method has no choice. It must be overridden.
2. TRUE or FALSE – during arithmetic, when the operands are of different types, the resulting type is ALWAYS the widest of the two types.
Answer: FALSE. The result of an arithmetic operation on any two primitive integer operands will be at least an int — even if the operands are byte and short.
3. Which of these operators would cause the bit pattern 00111100 to become 11000011? – (or) ~ (0r) !
Answer: The ~ operator performs a bitwise inversion (flips the bits)
4. Given x=y–; Which of these will be true AFTER execution?
a. x > y b. x == y c. x < y.
Answer: a (x > y). Because y is assigned to x and then y is decremented.
5. Can you automatically/implicitly covert a char to a short?
Answer: No. They’re the same bit-depth, bust since chars are unsigned, they might have a higher positive value than a short can accept.
6. TRUE or FALSE: If an exception is not caught, the finally block will run and the rest of the method is skipped.
Answer: TRUE. The finally block will always run if an exception is thrown, and then the exception is immediately passed to the calling method.
7. What happens when you bit shift by a number greater than or equal to the number of bits in the result? (Eg: int c=270, c>>33)
Answer: you get 270>>1. Shift bits by a number greater than or equal to the number of bits in the result (eg: 32 bits for an int) will cause the value to be shifted by the number modulo the number of bits in the value (you shift by 33%32 which is 1).
8. What happens when you have this in your code: double x; x=24.0/0;
Answer: Compiles and runs. Floating point numbers don’t produce a divide-by-zero Arithmetic Exception. They will give a result which is a Not a Number value.
9. Does a final variable have to be initialized at the time it’s declared?
Answer: No. Although early versions of the JDK enforced this, current version let you initialize a final variable in the constructor, but no later.
10. Can you automatically convert a long to an int if the long value is small enough to fit into an int?
Answer: No. A long has 64 bits while an int has 32. You can’t implicitly squish a *potentially* big thing into a little thing. The compiler doesn’t care if the long variable is holding a tiny value. It just looks for the possibility of trouble.
