A veces tenemos varias clases que tienen algunos métodos con la misma firma, pero que no corresponden a una interfaz Java declarada. Por ejemplo, ambosJTextField yJButton (entre varios otros enjavax.swing.*) tiene un método

public void addActionListener(ActionListener l)

Ahora, supongamos que deseo hacer algo con los objetos que tienen ese método; entonces, me gustaría tener una interfaz (o tal vez definirla yo mismo), por ejemplo,

  public interface CanAddActionListener {
      public void addActionListener(ActionListener l);
  }

para poder escribir:

  public void myMethod(CanAddActionListener aaa, ActionListener li) {
         aaa.addActionListener(li);
         ....

Pero, lamentablemente, no puedo:

     JButton button;
     ActionListener li;
     ...
     this.myMethod((CanAddActionListener)button,li);

Este elenco sería ilegal. El compilador sabe eseJButton no e a CanAddActionListener, porque la clase no ha declarado implementar esa interfaz ...sin embargo, "en realidad" lo implementa.

Esto a veces es un inconveniente, y el propio Java ha modificado varias clases principales para implementar una nueva interfaz hecha de métodos antiguos String implements CharSequence, por ejemplo)

Mi pregunta es: ¿por qué esto es así? Entiendo la utilidad de declarar que una clase implementa una interfaz. Pero de todos modos, mirando mi ejemplo, ¿por qué el compilador no puede deducir que la claseJButton "satisface" la declaración de interfaz (mirando dentro de ella) y acepta el reparto? ¿Es un problema de eficiencia del compilador o hay problemas más fundamentales?

Mi resumen de las respuestas: Este es un caso en el que Java podría haber tenido en cuenta algunos "tipeos estructurales" (una especie de tipeo de pato, pero verificado en tiempo de compilación). No lo hizo. Además de algunas dificultades (poco claras para mí) de rendimiento e implementación, aquí hay un concepto mucho más fundamental: en Java, la declaración de una interfaz (y en general, de todo) no pretende ser simplementeestructura (para tener métodos con estas firmas) perosemántic: se supone que los métodos implementan algún comportamiento / intento específico. Entonces, una clase que estructuralmente satisface alguna interfaz (es decir, tiene los métodos con las firmas requeridas) no necesariamente la satisface semánticamente (un ejemplo extremo: ¡recuerda las "interfaces de marcador", que ni siquiera tienen métodos!). Por lo tanto, Java puede afirmar que una clase implementa una interfaz porque (y solo porque) esto se ha declarado explícitamente. Otros idiomas (Go, Scala) tienen otras filosofías.