Interface or Abstract Class?

I primarily write server code in Java, for context.

I write interfaces in 2 primary situations:

1. Any time I need a contract between major modules, or between my code and code someone else owns. The contract includes the interface definition(s) and all the types that pass through that interface. That’s a package, and is declared as such.
2. Any time I design a general-purpose process which takes different implementations. Right now, for example, I am working on a machine that executes tasks in a sequence depending on the outcome of the previous task. The interface for each task has a single execute method which takes a process status object and returns one of 4 results, all of which are defined in an enumeration.

I seldom write abstract classes—but when I do, they generally implement an interface, and are intended to remove a lot of boilerplate code so implementers don’t have to fully understand the interface behavior to use it effectively. Abstract classes are a lot more common (and have a lot more use cases) in frameworks. Framework developers do this more than server engineers because their software is intended to be extended by others, whereas my software is usually intended as an end in itself.