10 Tricky Java Interview Question - Answered
10 Tricky Java Interview Question - Answered
10 Tricky Java Interview Question - Answered
What will happen if you put return statement or System.exit () on try or catch
block? Will finally block execute?
This is a very popular tricky Java question and it's tricky because many programmers
think that no matter what, but the finally block will always execute. This question
challenge that concept by putting a return statement in the try or catch block or
calling System.exit() from try or catch block. Answer of this tricky question in Java is
that finally block will execute even if you put a return statement in the try block or catch
block but finally block won't run if you call System.exit() from try or catch block.
Similarly, you cannot override a private method in sub class because it's not accessible
there, what you do is create another private method with the same name in the child
class. See Can you override a private method in Java or more details.
Question: What do the expression 1.0 / 0.0 will return? will it throw Exception?
any compile time error?
Answer: This is another tricky question from Double class. Though Java developer
knows about the double primitive type and Double class, while doing floating point
arithmetic they don't pay enough attention to Double.INFINITY, NaN, and -0.0 and
other rules that govern the arithmetic calculations involving them. The simple answer to
this question is that it will not throw ArithmeticExcpetion and
return Double.INFINITY.
Also, note that the comparison x == Double.NaN always evaluates to false, even if x
itself is a NaN. To test if x is a NaN, one should use the method
call Double.isNaN(x) to check if given number is NaN or not. If you know SQL, this is
very close to NULL there.
Btw, If you are running out of time for your interview preparation, you can also check
out Java Programming Interviews exposed for more of such popular questions,
Does Java support multiple inheritances?
This is the trickiest question in Java if C++ can support direct multiple inheritances than
why not Java is the argument Interviewer often give. Answer of this question is much
more subtle then it looks like, because Java does support multiple inheritances of Type
by allowing an interface to extend other interfaces, what Java doesn't support is multiple
inheritances of implementation. This distinction also gets blur because of default
method of Java 8, which now provides Java, multiple inheritances of behavior as well.
See why multiple inheritances are not supported in Java to answer this tricky Java
question.
What will happen if we put a key object in a HashMap which is already there?
This tricky Java question is part of another frequently asked question, How HashMap
works in Java. HashMap is also a popular topic to create confusing and tricky question
in Java. Answer of this question is if you put the same key again then it will replace the
old mapping because HashMap doesn't allow duplicate keys. The Same key will result
in the same hashcode and will end up at the same position in the bucket.
Each bucket contains a linked list of Map.Entry object, which contains both Key and
Value. Now Java will take the Key object from each entry and compare with this new
key using equals() method, if that return true then value object in that entry will be
replaced by new value. See How HashMap works in Java for more tricky Java
questions from HashMap.
Answer: The trickiness of this question lies on character encoding and how String to
byte array conversion works. In this program, we are first creating a String from a
character array, which just has one character '\u0097', after that we are getting the
byte array from that String and printing that byte. Since \u0097 is within the 8-bit range
of byte primitive type, it is reasonable to guess that the str.getBytes() call will
return a byte array that contains one element with a value of -105 ((byte) 0x97).
However, that's not what the program prints and that's why this question is tricky. As a
matter of fact, the output of the program is operating system and locale dependent. On
a Windows XP with the US locale, the above program prints [63], if you run this program
on Linux or Solaris, you will get different values.
To answer this question correctly, you need to know about how Unicode characters are
represented in Java char values and in Java strings, and what role character encoding
plays in String.getBytes().
In simple word, to convert a string to a byte array, Java iterate through all the characters
that the string represents and turn each one into a number of bytes and finally put the
bytes together. The rule that maps each Unicode character into a byte array is called a
character encoding. So It's possible that if same character encoding is not used during
both encoding and decoding then retrieved value may not be correct. When we
call str.getBytes() without specifying a character encoding scheme, the JVM uses
the default character encoding of the platform to do the job.
The default encoding scheme is operating system and locale dependent. On Linux, it
is UTF-8 and on Windows with a US locale, the default encoding is Cp1252. This
explains the output we get from running this program on Windows machines with a US
locale. No matter which character encoding scheme is used, Java will always translate
Unicode characters not recognized by the encoding to 63, which represents the
character U+003F (the question mark, ?) in all encodings.
How do you ensure that N thread can access N resources without deadlock?
If you are not well versed in writing multi-threading code then this is a real tricky
question for you. This Java question can be tricky even for the experienced and senior
programmer, who are not really exposed to deadlock and race conditions. The key point
here is ordering, if you acquire resources in a particular order and release resources in
the reverse order you can prevent deadlock. See how to avoid deadlock in Java for a
sample code example.
Question: Consider the following Java code snippet, which is initializing two
variables and both are not volatile, and two threads T1 and T2 are modifying
these values as following, both are not synchronized
int x = 0;
boolean bExit = false;
Answer: It's impossible for a list of tricky Java questions to not contain anything from
multi-threading. This is the simplest one I can get. Answer of this question is Yes, It's
possible that thread T2 may print x=0.Why? because without any instruction to compiler
e.g. synchronized or volatile, bExit=true might come before x=1 in compiler
reordering. Also, x=1 might not become visible in Thread 2, so Thread 2 will load x=0.
Now, how do you fix it?
When I asked this question to a couple of programmers they answer differently, one
suggests to make both threads synchronized on a common mutex, another one said
make both variable volatile. Both are correct, as it will prevent reordering and guarantee
visibility.
But the best answer is you just need to make bExit as volatile, then Thread 2 can only
print “x=1”. x does not need to be volatile because x cannot be reordered to come
after bExit=true when bExit is volatile.
This was my list of Some of the most common tricky questions in Java. It's not a bad idea to
prepare tricky Java question before appearing for any core Java or J2EE interview. One or
two open-ended or tricky question is quite common in Java interviews.
Further Reading
If you are looking for super challenging trick coding questions then you should check out
Joshua Bloch another classic book, the Java Puzzlers, I am sure you ill find them really
challenging to solve, I certainly did.