Effective Java By Josh Bloch

Recently i and my wife Sneha completed 2nd time Revision of My Fav developer Josh Bloch's Effective Java

Here is the recap of all the items mentioned in the book.

2 Creating and Destroying Objects
Item 1: Consider providing static factory methods instead of constructors
Item 2: Enforce the singleton property with a private constructor
Item 3: Enforce noninstantiability with a private constructor
Item 4: Avoid creating duplicate objects
Item 5: Eliminate obsolete object references
Item 6: Avoid finalizers

3 Methods Common to All Objects
Item 7: Obey the general contract when overriding equals
Item 8: Always override hashCode when you override equals
Item 9: Always override toString
Item 10: Override clone judiciously
Item 11: Consider implementing Comparable

4 Classes and Interfaces
Item 12: Minimize the accessibility of classes and members
Item 13: Favor immutability
Item 14: Favor composition over inheritance
Item 15: Design and document for inheritance or else prohibit it
Item 16: Prefer interfaces to abstract classes
Item 17: Use interfaces only to define types
Item 18: Favor static member classes over nonstatic

5 Substitutes for C Constructs
Item 19: Replace structures with classes
Item 20: Replace unions with class hierarchies
Item 21: Replace enum constructs with classes
Item 22: Replace function pointers with classes and interfaces

6 Methods
Item 23: Check parameters for validity
Item 24: Make defensive copies when needed
Item 25: Design method signatures carefully
Item 26: Use overloading judiciously
Item 27: Return zero-length arrays, not nulls
Item 28: Write doc comments for all exposed API elements

7 General Programming
Item 29: Minimize the scope of local variables
Item 30: Know and use the libraries
Item 31: Avoid float and double if exact answers are required
Item 32: Avoid strings where other types are more appropriate
Item 33: Beware the performance of string concatenation
Item 34: Refer to objects by their interfaces
Item 35: Prefer interfaces to reflection
Item 36: Use native methods judiciously
Item 37: Optimize judiciously
Item 38: Adhere to generally accepted naming conventions

8 Exceptions
Item 39: Use exceptions only for exceptional conditions
Item 40: Use checked exceptions for recoverable conditions and run-time exceptions for programming errors
Item 41: Avoid unnecessary use of checked exceptions
Item 42: Favor the use of standard exceptions
Item 43: Throw exceptions appropriate to the abstraction
Item 44: Document all exceptions thrown by each method
Item 45: Include failure-capture information in detail messages
Item 46: Strive for failure atomicity
Item 47: Don't ignore exceptions

9 Threads
Item 48: Synchronize access to shared mutable data
Item 49: Avoid excessive synchronization
Item 50: Never invoke wait outside a loop
Item 51: Don't depend on the thread scheduler
Item 52: Document thread safety
Item 53: Avoid thread groups

10 Serialization
Item 54: Implement Serializable judiciously
Item 55: Consider using a custom serialized form
Item 56: Write readObject methods defensively
Item 57: Provide a readResolve method when necessary

I think it is golden book surely to be read by every java developer to be precise.

I strongly believe Most of the items are well known by this time for all developers.

a)
Item 5 states that Eliminate obsolete object references.

For example: Lets say we are implementing Stack class and had a pop operation()?

public class Stack {

private Object[] elements;
private int size = 0;

 public Stack(int initialCapacity) {
 this.elements = new Object[initialCapacity];
 }

public Object pop() {
if (size == 0)
throw new EmptyStackException();
return elements[--size];
}
.... rest eliminated
}

Can we spot out the problem in this code mainly in pop() operation.

This program has a "memory leak," which can silently manifest itself as reduced performance.

This is because the stack maintains obsolete references to these objects.

An obsolete reference is a reference that will never be dereferenced again. In this case,
any references outside of the "active portion" of the element array are obsolete.

Fix for this problem?

public Object pop() {
if (size==0)
throw new EmptyStackException();
Object result = elements[--size];
elements[size] = null; // Eliminate obsolete reference
return result;
}

b) Not sure in which item but it says we need to hide implementation details to the user and instead return public interface for access.

For example

List list=new ArrayList();
Iterator iterator=list.iterator();

when we call list.iterator() method superclass AbstractList class iterator() method is called and it returns a public Iterator interface back to the user but it internally uses a private Itr implementation class. Clever way Isn't it?

public class ArrayList extends extends AbstractList<E>
        implements List<E>, RandomAccess, Cloneable, java.io.Serializable {

 .........
 }

public abstract class AbstractList<E> extends AbstractCollection<E> implements List<E> {
    public Iterator<E> iterator() {
 return new Itr();
    }

       private class Itr implements Iterator<E> {
 ......
       }
    ......
}

c) Item 51 says Don't depend on the thread scheduler.

Any program that relies on the thread scheduler for its correctness or performance is likely to be nonportable.

Thread priorities are among the least portable features of the Java platform. It is not
unreasonable to tune the responsiveness of an application by tweaking a few thread priorities,
but it is rarely necessary, and the results will vary from JVM implementation to JVM
implementation. It is unreasonable to solve a serious liveness problem by adjusting thread
priorities; the problem is likely to return until you find and fix the underlying cause.

The only use that most programmers will ever have for Thread.yield is to artificially
increase the concurrency of a program during testing.


Hope you may and read this book if not read till now.