Pourquoi déclarer une méthode d’interface Java comme abstraite?

J’ai utilisé la fonctionnalité de refactorisation “pull interface” d’Eclipse aujourd’hui pour créer une interface basée sur une classe existante. La boîte de dialog proposait de créer toutes les nouvelles méthodes de la nouvelle interface en tant que méthodes “abstraites”.

Quel serait l’avantage de cela?

Je pensais que le fait que vous ayez été autorisé à déclarer des méthodes d’interface comme abstraites était une caractéristique superflue et inoffensive du langage qui n’était pas particulièrement encouragée.

Pourquoi Eclipse soutiendrait-il un tel style, ou pourquoi quelqu’un choisirait-il volontairement de le faire?

Clarification: je ne demande pas pourquoi les méthodes d’interface sont abstraites, c’est évident. Je me demande pourquoi on choisirait explicitement de les marquer comme abstraits car s’ils sont dans une interface, ils sont de toute façon abstraits.

Selon la spécification de langage Java , le mot-clé abstract pour les interfaces est obsolète et ne doit plus être utilisé. (Section 9.1.1.1)

Cela dit, avec la propension de Java à la rétrocompatibilité, je doute fort que le mot-clé abstract soit présent.

“Le bénéfice de cela” (l’ajout de résumé sur la déclaration des méthodes d’interface) dans eclipse serait un ancien problème de compatibilité avec le compilateur jdt eclipse dans jdk1.3

Depuis la version 1.4, les bibliothèques jdk ne contiennent plus de méthodes abstraites par défaut (sur les classes abstraites implémentant des interfaces).
Cela trompe le diagnostic du compilateur Eclipse 1.3 car leur implémentation repose sur leur existence.
Notez que Javac 1.3 refuserait complètement d’opérer contre les bibliothèques 1.4 (en utilisant l’option -bootclasspath).

Étant donné que le compilateur Eclipse est probablement au niveau de conformité 1.4 (voir Workbench>Preferences>Java>Comstackr>JDK Compliance ) ou utilise au moins la bibliothèque de classes 1.3 si vous utilisez le mode de conformité 1.3, la présence de «abstract» n’est pas requirejse des projets d’éclipse actuels.

A partir du JLS (Java Language Specification) Java SE 7 : “Il est permis, mais déconseillé par style, de spécifier de manière redondante le modificateur public et / ou abstract pour une méthode déclarée dans une interface.”

Pour Java SE 5.0 : “Pour des raisons de compatibilité avec les anciennes versions de la plate-forme Java, il est autorisé mais déconseillé, par style, de spécifier de manière redondante le modificateur abstrait pour les méthodes déclarées dans les interfaces.”

Selon les méthodes JLS dans les interfaces sont abstraites par défaut, le mot clé est donc redondant. Sachant cela, je ne l’utilisais jamais pour “éviter le fouillis de présentation”.