Something that could easily be missed when programming in Java is inadvertently exposing the internals of a supposedly encapsulated field to clients of your class. Consider the following naive implementation of a rectangle class that disallows negative dimensions:

public final class MyRectangle {
private final Dimension dim;

public MyRectangle(Dimension dim) {
if( dim.height < 0 || dim.width < 0 ) {
throw new IllegalArgumentException("Dimensions cannot be negative");
}

this.dim = dim;
}

public int getArea() {
return dim.height * dim.weight;
}
}

A cursory glance may seem indicate that the class should be immutable and no negative dimensions, and thus no negative areas, are possible. Not true. Consider this bit of code that uses the MyRectangle class:

Dimension dim = new Dimension(2, 3);
MyRectangle rect = new MyRectangle(dim);
dim.setSize(-3, 4); // modifies rect's internal Dimension field!

This is possible because Dimension is a mutable class! Therefore, it is important to make a defensive copy of each parameter to the constructor that is mutable. We can fix the MyRectangle class by changing it's constructor like so:

public MyRectangle(Dimension dim) {
this.dim = new Dimension(dim); // make defensive copy

if( dim.height < 0 || dim.width < 0 ) {
throw new IllegalArgumentException("Dimensions cannot be negative");
}
}
Notice how a copy of the Dimension parameter is made, so that the client has no reference (and thus no access) to the internal dim field of the MyRectangle object. The same has to be done in the case where accessors return mutable fields - make sure to return defensive copies. The rule is never to directly return the internal field to a client class - always create a defensive copy and return that instead, so that there is no handle into the object internals.