Java Interview Questions: Basics II

Here are another set of questions asked in interviews that test one’s foundation knowledge or concepts in Java. We read these once and tend to forget. We can only remember these tips when you regularly start using these in your programming. Let’s begin.

Q1. Which of these is thread-safe? “StringBuilder” or “StringBuffer”?

Ans. StringBuffer is synchronised, thus making it slower than the StringBuilder.

Q2. Why a String is immutable in Java?

Ans. By design, Java maintains the strings in a particular way. It has a String constant pool where all the string literals are stored. When a new string is created, it first checks if the literal is already present in the pool. If it finds one, it just returns the reference to the variable instead of creating a new literal in the memory. Thus, a single string literal in the memory can have multiple references. So, if strings weren’t immutable, changing this string literal will also affect the other references which of-course is dangerous and undesired. This is why Strings are immutable. For this reason, the String class is also marked as final so that it’s functionality cannot be over-ridden, and thus the Strings remain as immutable for everyone.

Q3. What is the difference between these two statements?

String s1 = “abc”;    and String s2 = new String(“def”);

Ans. In the first case, “abc” will go into the string constant pool and s1 will refer to it. While in the second statement, since we have mentioned the new keyword, a new string object will be created in the normal(non-pool) memory, and s2 will refer to it. Additionally, the literal “def” will be placed in the pool.

Q4. Why should we prefer not to use Strings when we need to modify it’s value again and again?

Ans. As we just discussed, every string created in the Java, puts the literal in the memory pool. So, even if a literal has no more references to it, it will still be in the memory in an abandoned state. Thus, when constant modification operations are required to be made, at the end, we might have a large number of abandoned string literals in the memory which are of no use. In such cases, we should use StringBuffer or Stringbuilder, which can be modified over and over again without filling up the memory with abandoned literals.

Q5. What is the importance of close() and flush() in file or stream I/O ?

Ans. When we are done with reading or writing, we should always close the Reader or Writer objects, so that the resources could be freed up for others to use. To do this, we should call close() method on those objects.

While writing to a file/stream, some amount of buffering is always carried out, instead of putting the data character by character or byte by byte. So, if you don’t flush the stream, before closing the Writer object, whatever data is in the buffer, will never be written onto the file/stream. So, it is always a good practice to use flush() just before close().

Q6. What are the three principles of OOP?

Ans. Encapsulation, Polymorphism and Inheritance. You would say that everyone knows this. But I was surprised when someone asked me this question. I wasn’t able to remember the word “Encapsulation”. That was really strange!!!!!   :)

Q7. What type of parameter passing does Java support?

Ans. Java supports only “Passing by values”.

Q8. Can I write multiple main methods in a class?

Ans. Yes, you can do that, but there should be one which should be declared “public static void main(String[] args){}”.

Q9. Can constructors be overridden in a sub-class?

Ans. Constructors are not inherited by a sub-class when it extends another class. Thus, there is no question of overriding a constructor.

Q10. Can a constructor have a return type?

Ans. No, if you specify a constructor with a return type, be it void, it won’t be treated as a constructor any more. It will be treated as a normal method of that class, even if the name of the method matches with the class name.

More questions would follow. If you have doubts, please comment and I will try to answer your queries as soon as possible.