This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
With abstract classes, you can choose to implement some of the functionality, while leaving other functionality abstract. This way code that should be shared by many implementations can already be provided.
The Collections framework uses both: interfaces for defining the functionality, and abstract classes implementing those to provide basic functionality. For instance, when you want to write a new Collection implementation, you can just extend AbstractCollection and don't have to worry about methods as addAll, removeAll, containsAll and retainAll.
I'm not really adding anything new here -- just providing an illustration of what Rob described above.
Suppose an interface declares 20 methods. If you implement this, you need to write functionality for 20 methods. But an abstract class could implement that interface and provide basic functionality for 16 of these methods, leaving the other 4 abstract. This way, it's done most of the work for you. So instead of implementing the interface, you can extend the abstract class, and you only need to write functionality for 4 methods instead of 20. (Of course, if you don't like the way the abstract class has implemented the other methods, you can override these with your own functionality.)
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org