Default methods

Question

I read the Java tutorial on default methods and I think I understand how interfaces may evolve without loss of backward compatibility. My question refers rather to how should we design our interfaces from scratch. If and when should we define default methods? As an extreme example, why not design MyNewInterface with all default methods? If some operation makes sense, fine, stick the appropriate code in there, and if not, just do nothing, return null, return 0, return false. This would give the implementers of my interface quite some freedom what to care about, depending on their application needs and would make their apps less verbose (kind of like what the awt Adapter classes achieve). I don't look for an approval of this approach, but at some guidelines. Hope this makes sense.
Edit: And one more question from someone involved a lot with libraries for external clients. Does it make sense to rewrite old interfaces in a new release of the library and turn some methods into default methods containing code that makes sense? This option was not available so far and users had to write sometimes trivial implementations.

Answer 1

So:
cool stuff for backward compatibility
probably not as compatible as you think
but...
how should we design new interfaces?
For *new* interfaces, including default methods is not going to break anything (at least, not immediately, see later). I think, use this sparingly: if you genuinely have an example of "every object of this type should have this functionality", *and* there's an obvious default implementation, then that's probably a good case for using default methods.
So , consider a DAO interface. You'll commonly want to get an object via it's id. The database stores the id as an int, and the corresponding class has an id field of type Integer. So it's fairly intuitive to define
public interface DAO {
    public Entity getEntity(int id) ;
But... all (or the vast majority) of my use cases are in a web application, and of course the only data type http knows about is String. So at some point, I get a request parameter representing the id as a String, and have to convert it to an int in order to get the entity from the DAO. In other words, I end up doing this:
DAO dao ;
String idFromRequest = request.getParameter("id");
Entity entity = dao.getEntity(Integer.parseInt(idFromRequest));
I end up really needing DAO to support a
public Entity getEntity(String id);
method, but do I really want to force all implementations to implement it to call Integer.parseInt(...) to invoke the other method?
I could, of course, define an AbstractDAO class that adds the method in, but then I lose the whole "programming to interfaces" paradigm.
So that would (at least, on the surface) appear to be a nice use case for default methods.
You should still worry a bit. Even if I put a default method into a new interface, any classes that implement that interface and some other interface are vulnerable to breaking if the other interface later introduces a default method with the same signature as my default method. So you might want to think about making those default method names quite specific.
Default methods should be used sparingly. If you add dozens of them to your libraries, you increase the risk of problems caused later by classes not being able to resolve calls unambiguously.