¿Por qué no está permitido "final" en los métodos de interfaz Java 8?

Una de las características más útiles de Java 8 son los nuevos defaultmétodos en las interfaces. Básicamente, hay dos razones (puede haber otras) por las que se han introducido:

• Proporcionar implementaciones predeterminadas reales. Ejemplo:Iterator.remove()
• Permitiendo la evolución de la API JDK. Ejemplo:Iterable.forEach()

Desde la perspectiva de un diseñador de API, me hubiera gustado poder usar otros modificadores en los métodos de interfaz, por ejemplo final. Esto sería útil al agregar métodos de conveniencia, evitando anulaciones "accidentales" en la implementación de clases:

interface Sender {

    // Convenience method to send an empty message
    default final void send() {
        send(null);
    }

    // Implementations should only implement this method
    void send(String message);
}

Lo anterior ya es una práctica común si Senderfuera una clase:

abstract class Sender {

    // Convenience method to send an empty message
    final void send() {
        send(null);
    }

    // Implementations should only implement this method
    abstract void send(String message);
}

Ahora, defaulty finalobviamente son palabras clave contradictorias, pero la palabra clave predeterminada en sí misma no habría sido estrictamente requerida , por lo que supongo que esta contradicción es deliberada, para reflejar las sutiles diferencias entre "métodos de clase con cuerpo" (solo métodos) e "interfaz métodos con cuerpo " (métodos predeterminados), es decir, diferencias que aún no he entendido.

En algún momento, el soporte para modificadores como staticy finalen los métodos de interfaz aún no se había explorado por completo, citando a Brian Goetz :

La otra parte es hasta dónde vamos a llegar para admitir herramientas de creación de clases en interfaces, como métodos finales, métodos privados, métodos protegidos, métodos estáticos, etc. La respuesta es: todavía no lo sabemos

Desde ese momento a finales de 2011, obviamente, staticse agregó soporte para métodos en interfaces. Claramente, esto agregó mucho valor a las propias bibliotecas JDK, como con Comparator.comparing().

Pregunta:

¿Cuál es la razón final(y también static final) nunca llegó a las interfaces Java 8?

Esta pregunta está, hasta cierto punto, relacionada con ¿Cuál es la razón por la cual "sincronizado" no está permitido en los métodos de interfaz Java 8?

La clave para comprender los métodos predeterminados es que el objetivo principal del diseño es la evolución de la interfaz , no "convertir las interfaces en rasgos (mediocres)". Si bien existe cierta superposición entre los dos, y tratamos de acomodarnos al último donde no se interpuso en el primero, estas preguntas se entienden mejor cuando se consideran desde esta perspectiva. (Nota también que los métodos de clase se van a ser diferente de métodos de interfaz, no importa cuál es la intención, en virtud del hecho de que los métodos de interfaz pueden ser heredados se multiplican.)

La idea básica de un método predeterminado es: es un método de interfaz con una implementación predeterminada, y una clase derivada puede proporcionar una implementación más específica. Y debido a que el centro de diseño fue la evolución de la interfaz, era un objetivo de diseño crítico que los métodos predeterminados se pudieran agregar a las interfaces después del hecho de una manera compatible con la fuente y compatible con el binario.

La respuesta demasiado simple a "por qué no los métodos predeterminados finales" es que el cuerpo no sería simplemente la implementación predeterminada, sino que sería la única implementación. Si bien esa es una respuesta demasiado simple, nos da una pista de que la pregunta ya se dirige en una dirección cuestionable.

Otra razón por la cual los métodos de interfaz finales son cuestionables es que crean problemas imposibles para los implementadores. Por ejemplo, suponga que tiene:

interface A { 
    default void foo() { ... }
}

interface B { 
}

class C implements A, B { 
}

Aquí todo está bien; Chereda foo()de A. Ahora supongamos que Bse cambia para tener un foométodo, con un valor predeterminado:

interface B { 
    default void foo() { ... }
}

Ahora, cuando vamos a recompilar C, el compilador nos dirá que no sabe para qué comportamiento heredar foo(), por lo que Ctiene que anularlo (y podría elegir delegar A.super.foo()si quería retener el mismo comportamiento). Pero qué pasa si Bhabía hecho su defecto final, y Ano está bajo el control del autor de C? Ahora Cestá irremediablemente roto; no puede compilar sin anular foo(), pero no puede anular foo()si fue finalizado B.

Este es solo un ejemplo, pero el punto es que la finalidad de los métodos es realmente una herramienta que tiene más sentido en el mundo de las clases de herencia única (generalmente, que combinan el estado con el comportamiento), que con las interfaces que simplemente contribuyen al comportamiento y pueden multiplicarse. heredado. Es demasiado difícil razonar sobre "qué otras interfaces podrían mezclarse en el eventual implementador", y permitir que un método de interfaz sea final probablemente causaría estos problemas (y no explotarían en la persona que escribió la interfaz, sino en el usuario pobre que intenta implementarlo)

Otra razón para no permitirlos es que no significarían lo que crees que significan. Una implementación predeterminada solo se considera si la clase (o sus superclases) no proporcionan una declaración (concreta o abstracta) del método. Si un método predeterminado fuera definitivo, pero una superclase ya implementara el método, el predeterminado sería ignorado, lo que probablemente no sea lo que el autor predeterminado esperaba al declararlo como final. (Este comportamiento de herencia es un reflejo del centro de diseño para los métodos predeterminados: evolución de la interfaz. Debería ser posible agregar un método predeterminado (o una implementación predeterminada a un método de interfaz existente) a las interfaces existentes que ya tienen implementaciones, sin cambiar el comportamiento de las clases existentes que implementan la interfaz,

En la lista de correo lambda hay muchas discusiones al respecto . Uno de los que parece contener mucha discusión sobre todas esas cosas es el siguiente: Visibilidad del método de interfaz variada (fue Defensores finales) .

En esta discusión, Talden, el autor de la pregunta original, hace algo muy similar a su pregunta:

La decisión de hacer públicos todos los miembros de la interfaz fue una decisión desafortunada. Que cualquier uso de la interfaz en el diseño interno expone los detalles privados de la implementación es importante.

Es difícil de solucionar sin agregar algunos matices oscuros o que rompen la compatibilidad al lenguaje. Una ruptura de compatibilidad de esa magnitud y sutileza potencial sería inconcebible, por lo que debe existir una solución que no rompa el código existente.

Podría reintroducir la palabra clave 'paquete' como un especificador de acceso ser viable. Su ausencia de un especificador en una interfaz implicaría acceso público y la ausencia de un especificador en una clase implica acceso de paquete. No está claro qué especificadores tienen sentido en una interfaz, especialmente si, para minimizar la carga de conocimiento sobre los desarrolladores, tenemos que asegurarnos de que los especificadores de acceso signifiquen lo mismo tanto en clase como en interfaz si están presentes.

En ausencia de métodos predeterminados, habría especulado que el especificador de un miembro en una interfaz debe ser al menos tan visible como la interfaz en sí (para que la interfaz se pueda implementar en todos los contextos visibles), con métodos predeterminados que no son muy seguro

¿Ha habido alguna comunicación clara sobre si esto es incluso una posible discusión dentro del alcance? Si no, debería celebrarse en otro lugar.

Finalmente, la respuesta de Brian Goetz fue:

Sí, esto ya está siendo explorado.

Sin embargo, permítame establecer algunas expectativas realistas: las funciones de lenguaje / VM tienen un tiempo de espera largo, incluso las que parecen triviales como esta. El tiempo para proponer nuevas ideas de características de lenguaje para Java SE 8 ya pasó.

Por lo tanto, lo más probable es que nunca se implementó porque nunca fue parte del alcance. Nunca fue propuesto a tiempo para ser considerado.

En otra acalorada discusión sobre los métodos de defensa final sobre el tema, Brian dijo nuevamente :

Y has obtenido exactamente lo que deseaste. Eso es exactamente lo que agrega esta característica: herencia múltiple de comportamiento. Por supuesto, entendemos que las personas los usarán como rasgos. Y hemos trabajado arduamente para garantizar que el modelo de herencia que ofrecen sea lo suficientemente simple y limpio como para que las personas puedan obtener buenos resultados al hacerlo en una amplia variedad de situaciones. Al mismo tiempo, hemos elegido no empujarlos más allá del límite de lo que funciona de manera simple y limpia, y eso lleva a reacciones de "aw, no fuiste lo suficientemente lejos" en algún caso. Pero realmente, la mayor parte de este hilo parece estar refunfuñando que el vidrio está lleno al 98%. ¡Tomaré ese 98% y seguiré con eso!

Entonces esto refuerza mi teoría de que simplemente no era parte del alcance o parte de su diseño. Lo que hicieron fue proporcionar suficiente funcionalidad para lidiar con los problemas de la evolución de la API.

Será difícil encontrar e identificar "la" respuesta, por las razones de fuerza mencionados en los comentarios de @EJP: Hay aproximadamente 2 (+/- 2) personas en el mundo que puede dar la respuesta definitiva en absoluto . Y en caso de duda, la respuesta podría ser algo así como "Apoyar los métodos predeterminados finales no parecía valer la pena el esfuerzo de reestructurar los mecanismos internos de resolución de llamadas". Esto es especulación, por supuesto, pero al menos está respaldado por evidencias sutiles, como esta Declaración (de una de las dos personas) en la lista de correo de OpenJDK :

"Supongo que si se permitieran los métodos" predeterminados finales ", podrían necesitar una reescritura desde la invocación interna especial a la interfaz de invocación visible para el usuario".

y hechos triviales como ese, un método simplemente no se considera un método (realmente) final cuando es un defaultmétodo, como se implementa actualmente en el método Method :: is_final_method en OpenJDK.

Además, la información realmente "autoritaria" es realmente difícil de encontrar, incluso con búsquedas web excesivas y leyendo registros de confirmación. Pensé que podría estar relacionado con posibles ambigüedades durante la resolución de las llamadas a métodos de interfaz con las invokeinterfacellamadas de instrucción y y método de clase, que corresponde a la invokevirtualinstrucción: Para la invokevirtualinstrucción, puede haber un simple vtable de búsqueda, ya que el método sea debe ser heredado de una superclase, o implementado por la clase directamente. En contraste con eso, una invokeinterfacellamada debe examinar el sitio de la llamada respectiva para averiguar a qué interfaz se refiere realmente esta llamada (esto se explica con más detalle en la página InterfaceCalls de HotSpot Wiki). Sin embargo,finallos métodos no se insertan en la vtable en absoluto, o reemplazan las entradas existentes en la vtable (consulte klassVtable.cpp. Línea 333 ), y de manera similar, los métodos predeterminados están reemplazando las entradas existentes en la vtable (consulte klassVtable.cpp, Línea 202 ) . Entonces, la razón real (y, por lo tanto, la respuesta) debe ocultarse más profundamente dentro de los mecanismos de resolución de llamadas del método (bastante complejo), pero tal vez estas referencias se considerarán útiles, pero solo para otros que logran obtener la respuesta real a partir de ese.

No creo que sea necesario especificar finalun método de interfaz de conveniencia, aunque estoy de acuerdo en que puede ser útil, pero aparentemente los costos han superado los beneficios.

Lo que se supone que debe hacer, de cualquier manera, es escribir javadoc adecuado para el método predeterminado, mostrando exactamente qué es y qué no se permite hacer. De esa manera, las clases que implementan la interfaz "no están permitidas" para cambiar la implementación, aunque no hay garantías.

Cualquiera podría escribir una Collectionque se adhiera a la interfaz y luego haga cosas en los métodos que son absolutamente contrarios a la intuición, no hay forma de protegerse de eso, aparte de escribir pruebas unitarias extensas.

Agregamos defaultpalabras clave a nuestro método dentro de un interfacecuando sabemos que la clase que amplía interfacepuede o no overridenuestra implementación. Pero, ¿qué sucede si queremos agregar un método que no queremos que anule ninguna clase de implementación? Bueno, hay dos opciones disponibles para nosotros:

1. Agrega un default finalmétodo.
2. Agrega un staticmétodo.

Ahora, Java dice que si tenemos una classimplementación de dos o más de interfacesmanera que tengan un defaultmétodo con exactamente el mismo nombre y firma del método, es decir, que estén duplicados, entonces debemos proporcionar una implementación de ese método en nuestra clase. Ahora, en el caso de los default finalmétodos, no podemos proporcionar una implementación y estamos atascados. Y es por eso que la finalpalabra clave no se usa en las interfaces.