Default method survey results

[Stephen Colebourne]

On 13 August 2012 15:24, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> *) a keyword (like default) at the beginning of the method declaration
> will make it very clear and unambiguous that the following method
> declaration is kinda special. Of course you could 'infer' the same
> information by looking as to whether the method has a body or not, but
> it's also a matter of clarity (think of cases where you have multiple
> thrown types, annotations, etc.).

In Java, a method is defined by placing a block of code after a method
signature. There is no need to specify a loud "this is a method"
keyword. Of course, the previous sentence refers to classes, but it is
perfectly plain that once JDK8 is released, interfaces will act very
much like classes without fields that can be multiply inherited. The
team have worked hard to ensure that the inheritance is natural, yet
fight against the last step to make it be natural! Stop trying to make
it special simply because it is special to the compiler/JVM writer.

> *) Proposals for alternate ways of specifying default method
> implementations (i.e. other than specifying a method block) have been on
> the table for quite some time; i.e. use a method reference to denote the
> default implementation. Or some syntactic shorthand in case the only
> thing you need to do is to disambiguate between two superinterface
> members using a qualified super call. If such proposals will ever be
> part of the language, it will be increasingly difficult for the human
> reader to immediately grasp as to whether a method is a default method
> or not, as the proposed 'has a block?' rule of thumb would no longer hold.

The premise here is wrong. A method in JDK8, whether from an interface
or a class, will inherit in essentially the same way. Clashing
overrides are the main issue. Default-ness is not something a
developer actively cares about here, and does not need to be specially
marked.

Now consider this code:

interface Foo {
  public String process(int a, String b) default Utils#processFoo
}
class Bar {
  public String process(int a, String b) default Utils#processBar
}

The Foo version is being talked about for JDK8/9, yet the Bar version
isn't. Why not? What is the difference here that justifies support for
this feature in interfaces and not classes? None I'd suggest. But
here, a keyword of some sort does make some sense - its a new feature
not seen anywhere today. Methods that can be inherited are not a new
feature, just one appearing in a new location (interfaces), thats why
they don't need extra syntax.

Stephen