Oracle Blog

Innovate to simplify

Wednesday Jul 29, 2009

After quite some time I'm back , busy with my automation project and one parser development.

Recently I am exploring some java stuff which was ignore knowingly or do not care to understand funda behind it as long as work is getting done. So i thought of sharing some know items one more time to give them special attention.

Duplicate in HashMap : If new object hash code is same as existing member hashcode then if either new object == to existing object or new objects equals() return true then existing object will be updated. So overwite hashcode and equals() if you want to prevent duplicate based on class variable.

Ex .

Class Employee

{
int empNo;
String name;
int age;
}

You want collection to be store non duplicate based on empNo.

Then add following two overriding version of hashCode() and equals()
public int hashCode()

{
return empNo;
}

public boolean equals(Employee e)

{
return (this.empNo == e.empNo)?true:false;
}

Now when you will add to hashmap object of Employee , it will add new pair if and only if empNo will be different otherwise it will update the existing one

Transient - It flags a field as something that should not be considered part of an object's persistent state.
i.e. in simple terms it will not get written to persistence store (whatever it may be)
if this keyword is associated with variable
Reading and Writing shared variable by

Thread : Each thread has a working memory, in which it may keep copies of the values of variables from the main memory that is shared between all threads.

To access a shared variable, a thread usually first obtains a lock and flushes its working memory. This guarantees that shared values will thereafter be loaded from the shared main memory to the threads working memory. When a thread unlocks a lock it guarantees the values it holds in its working memory will be written back to the main memory.

Monitor : Not class monitor , its object monitor , Each object got monitor. Thread calling synchronized method or synchronized block of this object gets monitor(if available otherwise wait wait). if thread get monitor then others has to wait till finish to execute the same.

Reentrant Monitor : The Java runtime system allows a thread to re-acquire a monitor that it already holds because Java monitors are reentrant. Reentrant monitors are important because they eliminate the possibility of a single thread deadlocking itself on a monitor that it already holds.

notifyAll() : After effects , If multiple threads are waiting for a monitor, the Java runtime system chooses one of the waiting threads to run, making no commitments or guarantees about which thread will be chosen.

Lost a monitor blame wait() : When the thread enters the wait method, the monitor is released atomically, and when the thread exits the wait method, the monitor is acquired again

Lock a Class , what ? : Java virtual machine loads a class file, it creates an instance of class java.lang.Class. When you lock a class, you are actually locking that class's Class object. But why ? To enter in synchronized static method you need class lock.

Wait() ,notify(),notifyAll() : from where you will invoke , anywhere , no no , only from synchronized method/statement. You need to lock to execute this methods.

serialVersionUID : you better write if your object getting serialized. If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification. However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during de-serialization

Error Class : lost frontier , how long it will survive . An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch . A method is not required to declare in its throws clause any subclasses of Error that might be thrown during the execution of the method but not caught, since these errors are abnormal conditions that should never occur. ex. IOError , LinkageError , VirtualMachineError etc etc. Quite a few never knew they have good big family :-).

throw ? , what you can throw ? Only objects that are instances of this class (or one of its subclasses) are thrown by the Java Virtual Machine or can be thrown by the Java throw statement

catch ? What you can catch ? Similarly, only this class or one of its subclasses can be the argument type in a catch clause.

RunTimeException : luxury for not required to catch , should not be thrown in first place , go and fix root cause . A method is not required to declare in its throws clause any subclasses of RuntimeException that might be thrown during the execution of the method but not caught