Quick View - Java 7 Features

1. Up-gradation to class loader architecture to avoid deadlocks in non-hierarchical class-loader topologies.
2. A method has been added to free the underlying resources, such as open files, held by a URLClassLoader.
3. A lightweight fork/join framework, flexible and reusable synchronization barriers, transfer queues, a concurrent-reference HashMap, and thread-local pseudo-random number generators.
4. Upgraded to supported version of Unicode 6.0 for more from internationalization.
5. the java.util.Locale class to support IETF BCP 47 and UTR 35 now.
6. Now there will be a two separate locale for user and user-interface.
7. New APIs for filesystem access, scalable asynchronous I/O operations, socket-channel binding and configuration, and multicast datagrams
8. New fully functional file system provider NIO.2 for zip/jar archiving.
9. JDBC upgraded to 4.1 and Rowset to 1.1
10. XML stack is upgraded to new stable version for more on web.
11. JSR 292 providing support for dynamically typed language.

OutOfMemoryError: PermGen space while reloading webapp in tomcat

This annoying error of PermGen space OOMs when reloading the webapp in tomact is because in tomcat the class loader only loads the classes and this class loader and loaded classes are never garbage collected. Each time you reload your webapp, copies of classes will be added to memory, basically the permanent heap space used by tomcat. This eventually makes tomcat run out of memory to further carry out operation.

This is common and can happen with other containers also until unless in some version the owner have made changes to take care of this. Try reloading the application again and again until unless your container cry of Out of Memory Error. What we can do in such a situation is to restart the container which basically clean up the heap and load the application again.

Additionally try no putting your JDBC and commons jar in the WEB-INF. Instead you can put them in the TOMCAT-HOME/common/lib folder because these are already bootstrapped by tomcat. If you face issue of 'No suitable driver' Exception after placing your jdbc jar in tomcat common/lib, try adding you jndi db definition in context.xml like
<\Context path="/test" reloadable="true" debug="1">
<\Resource name="jdbc/db" auth="Container" type="javax.sql.DataSource" maxActive="30" maxIdle="3"
maxWait="10000" username="testing" password="testing" driverClassName="net.sourceforge.jtds.jdbc.Driver" url="jdbc:testdburl;lastupdatecount=true" />

equals and hashcode

Object equals will just compare references and hashcode is native which always return difference integer even if objects are same but different instances. So of you override equals and not hashcode for any object being used as a key in hashmap, then I will not get value corresponding to key because it wont be able to find hashcode for new instance of key. As it will look into the wrong bucket (new bucket) if I override hashcode and not equals, even there I wont be able to get the value because I can find the bucket but objects equal check references which will be different for stored object and my key object (new instance of old key object).

DB Connection class

DriverManager.getConnection (url, user, pwd).getClass().getName().equals("java.sql.Connection") = false

This is false because left hand side will return a class of the underlying database connection class i.e. oracle.jdbc.driver.OracleConnection in case of oracle. So this will be a instance of java.sql.Connection but can not be equal.

Cut rectangular cake half

Given a rectangular cake with rectangular piece removed (any size, any orientation), how would you cut remainder cake in two equal haves with one straight cut of knife.

Serializable Singleton

In a class write below code to prevent singleton class from losing its behavior if you make it serializable.

protected Object readResolve(){
    return singletonObj;
}

Deserialization creates another object instance, so to avoid that situation this needs to be done.

Java Threading

public static void myMethod(){
    synchronized(this){
        //do stuff
    }
}

This will not get a class level lock, many threads can enter this static method of class and with individual object lock can execute code in it.

public static synchronized void myMethod() {
    //do stuff
}
-----is equivalent to-----
public void myMethod(){
    synchronized(MyClass.class){
         //do stuff
    }
}

In both the case, threads will obtain a class level lock butt there will just be a difference of timing for how long lock is being obtained.

1. Threads that synchronize on the same object will block each other. Threads that synchronize on different objects will not.
2. A static synchronized method and a non-static synchronized method will not block each other, ever. The static method locks on a class instance while non-static method locks on this instance these actions do not interfere with each other at all.
3. Threads calling static synchronized methods in the same class will always block each other - they all lock the same class instance.
4. Threads calling non-static synchronized methods in the same class will only block each other if they are invoked using same instance.
5. A thread can acquire more that one lock. A thread can enter a synchronized method, acquiring a lock and then immediately invoke a synchronized method on a different object, acquiring that locak as well. A thread acquires a lock and then attempts to call a synchronized method on the same object, no problem because thread already have lock of this object.
6. If a class has both synchronized and non-synchronized methods, multiple threads can still access the class's non-synchronized methods.

Thread Join-
If you have a thread B that can't do its work until another thread A has completed its work, then you want B to join thread A.
This means that thread B will not become runnable until thread A has finished.
Thread t = new Thread();
t.start();
t.join();
This code take currently running thread and joins it to the end of thread t. Current thread become runnable after thread t is no longer alive.