The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Stubs and mocks, indeed, have a lot in common. They are not the "real" objects, and they can record information about what has been done with them.
According to Martin Fowler (see link above), the basic difference between stubs and mocks is that stubs use state verification and mocks use behavior verification.
In practice, if you write a class that implements the same interface as the "real" objects and provide some mechanisms for recording the state (e.g. how many times some method has been called), this is a stub. With mocks, in contrast, *every* method call is checked, and there is not a specific mechanism for recording some special events, rather expectations about *everything* (possibly with some exception) are set up and compared with what has really been called. Usually, it does not make sense, to write mocks from the ground up; rather, you should use a framework like EasyMock. If, however, you really implemented mocks from the ground up, in contrast to stubs, this would imply a heavy use of reflection.