¿Por qué uno declararía un método de interfaz Java como abstracto?

Question

Utilicé la función de refactorización de "interfaz de extracción" de Eclipse hoy para crear una interfaz basada en una clase existente. El cuadro de diálogo ofreció crear todos los nuevos métodos de la nueva interfaz como métodos "abstractos".

¿Cuál sería el beneficio de eso?

Pensé que el hecho de que se le permitiera declarar los métodos de interfaz como abstract era una característica superflua e inofensiva del lenguaje que no se recomienda especialmente.

¿Por qué Eclipse admitiría tal estilo, o por qué alguien voluntariamente lo haría?

Aclaración: No estoy preguntando por qué los métodos de interfaz son abstractos, eso es obvio. Me pregunto por qué uno elegiría explícitamente marcarlos como abstractos, ya que si están en una interfaz, de todos modos son abstractos.

Answer 1

De acuerdo con Java Language Specification, la palabra clave abstract para interfaces está obsoleta y ya no se debe usar. (Sección 9.1.1.1)

Dicho esto, con la propensión de Java hacia la compatibilidad con versiones anteriores, realmente dudo que alguna vez marque la diferencia si la palabra clave abstract está presente.

Answer 2

Según JLS, los métodos en las interfaces son abstractos por defecto, por lo que la palabra clave es redundante. Sabiendo esto, nunca lo usaría para "evitar el desorden de presentación".

Answer 3

"El beneficio de que" (añadiendo abstracta sobre métodos de interfaz declaración) en Eclipse sería un problema de compatibilidad de edad con jdt eclipse compiler in jdk1.3

Desde 1.4, bibliotecas JDK ya no se contiene métodos abstractos por defecto (en clases abstractas implementando interfaces).
Esto engaña al diagnóstico del compilador Eclipse 1.3 ya que su implementación se basa en su existencia.
Tenga en cuenta que Javac 1.3 se rehusaría por completo a funcionar en contra de las bibliotecas 1.4 (usando la opción -bootclasspath).

Desde el compilador Eclipse es probable que sea en 1.4 nivel de cumplimiento (ver Workbench>Preferences>Java>Compiler>JDK Compliance), o utilizar al menos 1,3 bibliotecas de clases si se utiliza 1.3 modo de cumplimiento, la presencia de "abstracto" no es necesaria en la mayor parte de la corriente proyectos de eclipse.

Answer 4

A partir del Java SE 7 JLS (Especificación del lenguaje Java): "Está permitido, pero desaconsejado como una cuestión de estilo, especificar de forma redundante el modificador público y/o abstracto para un método declarado en una interfaz".

Para Java SE 5.0: "Para la compatibilidad con las versiones anteriores de la plataforma Java, está permitido, pero desaconsejado, como una cuestión de estilo, especificar de forma redundante el modificador abstracto para los métodos declarados en las interfaces."