This is list of some Java fundamental questions and answers, which are commonly asked in a Core Java interview for Experienced Developers. As a senior and matured Java Programmer you must know the answers to these questions to demonstrate basic understanding of Java language and depth of knowledge.
- are simple to use test and construct.
- are automatically thread-safe.
- do not require a copy constructor.
- do not require an implementation of clone.
- allow hashCode to use lazy initialization, and to cache its return value.
- do not need to be copied defensively when used as a field.
- are good Map keys and Set elements (these objects must not change state while stored in the collection).
- have their class invariant established once upon construction, and it never needs to be checked again.
- always have "failure atomicity" (a term used by Joshua Bloch) : if an immutable object throws an exception, it's never left in an undesirable or indeterminate state.
- String class objects are immutable whereas StringBuffer and StringBuilder objects are mutable.
- StringBuffer is synchronized while StringBuilder is not synchronized.
- Concatenation operator "+" is internal implemented using either StringBuffer or StringBuilder.
- If the Object value is not going to change use String Class because a String object is immutable.
- If the Object value can change and will only be accessed from a single thread, use a StringBuilder because StringBuilder is unsynchronized.
- In case the Object value can change, and will be modified by multiple threads, use a StringBuffer because StringBuffer is synchronized.
- Immutable objects are thread-safe. Two threads can both work on an immutable object at the same time without any possibility of conflict.
- Security: the system can pass on sensitive bits of read-only information without worrying that it will be altered
- You can share duplicates by pointing them to a single instance.
- You can create substrings without copying. You just create a pointer into an existing base String guaranteed never to change. Immutability is the secret behind Java’s very fast substring implementation.
- Immutable objects are much better suited to be Hashtable keys. If you change the value of an object that is used as a hash table key without removing it and re-adding it you lose the mapping.
- Since String is immutable, inside each String is a char[] exactly the correct length. Unlike a StringBuilder there is no need for padding to allow for growth.
- If String were not final, you could create a subclass and have two strings that look alike when "seen as Strings", but that are actually different.
-
java.lang.OutOfMemoryError: Java heap space
The quick solution is to add these flags to JVM command line when Java runtime is started:- -Xms1024m -Xmx1024m
-
java.lang.OutOfMemoryError: PermGen space
The solution is to add these flags to JVM command line when Java runtime is started:- -XX:+CMSClassUnloadingEnabled-XX:+CMSPermGenSweepingEnabled
- If the JVM exits while the try or catch code is being executed, then the finally block may not execute. This may happen due to System.exit() call.
- if the thread executing the try or catch code is interrupted or killed, the finally block may not execute even though the application as a whole continues.
- If a exception is thrown in finally block and not handled then remaining code in finally block may not be executed.
A thin wrapper around a millisecond value that allows JDBC to identify this as an SQL DATE value. A milliseconds value represents the number of milliseconds that have passed since January 1, 1970 00:00:00.000 GMT. To conform with the definition of SQL DATE, the millisecond values wrapped by a java.sql.Date instance must be 'normalized' by setting the hours, minutes, seconds, and milliseconds to zero in the particular time zone with which the instance is associated.
Explanation: A java.util.Date represents date and time of day, a java.sql.Date only represents a date (the complement of java.sql.Date is java.sql.Time, which only represents a time of day, but also extends java.util.Date).- java.io.Serializable - Serializability of a class is enabled by the class implementing the java.io.Serializable interface. Classes that do not implement this interface will not have any of their state serialized or deserialized. All subtypes of a serializable class are themselves serializable. The serialization interface has no methods or fields and serves only to identify the semantics of being serializable.
- java.rmi.Remote - The Remote interface serves to identify interfaces whose methods may be invoked from a non-local virtual machine. Any object that is a remote object must directly or indirectly implement this interface. Only those methods specified in a "remote interface", an interface that extends java.rmi.Remote are available remotely.
- java.lang.Cloneable - A class implements the Cloneable interface to indicate to the Object.clone() method that it is legal for that method to make a field-for-field copy of instances of that class. Invoking Object's clone method on an instance that does not implement the Cloneable interface results in the exception CloneNotSupportedException being thrown.
- javax.servlet.SingleThreadModel - Ensures that servlets handle only one request at a time. This interface has no methods.
- java.util.EvenListener - A tagging interface that all event listener interfaces must extend.
The only difference between experienced and inexperienced software developers is that the experienced ones realize when they're making a mistake.