¿Deben declararse los métodos en una interfaz Java con o sin un modificador de acceso público?

El modificador público debe ser omitido en las interfaces Java (en mi opinión).

Dado que no agrega ninguna información adicional, simplemente aleja la atención de las cosas importantes.

La mayoría de las guías de estilo recomendarán que lo omitas, pero por supuesto, lo más importante es ser consistente en todo tu código base, y especialmente para cada interfaz. El siguiente ejemplo podría confundir fácilmente a alguien, que no es 100% fluido en Java:

public interface Foo{
  public void MakeFoo();
  void PerformBar();
}

A pesar del hecho de que esta pregunta se ha hecho hace mucho tiempo, pero siento que una descripción exhaustiva aclararía por qué no hay necesidad de usar abstract público antes de los métodos y public static final antes de las constantes de una interfaz.

En primer lugar, las interfaces se utilizan para especificar métodos comunes para un conjunto de clases no relacionadas para las que cada clase tendrá una implementación única. Por lo tanto, no es posible especificar el modificador de acceso como privado ya que no se puede acceder a él por otras clases para ser anuladas.

Segundo, aunque uno puede iniciar objetos de un tipo de interfaz, pero una interfaz es realizada por las clases que la implementan y no heredada. Y dado que una interfaz puede ser implementada (realizada) por diferentes clases no relacionadas que no están en el mismo paquete, el modificador de acceso protegido tampoco es válido. Así que para el modificador de acceso solo nos queda la opción pública.

Tercero, una interfaz no tiene ningún dato implementación incluyendo las variables y métodos de instancia. Si hay una razón lógica para insertar métodos implementados o variables de instancia en una interfaz, entonces debe ser una superclase en una jerarquía de herencia y no una interfaz. Teniendo en cuenta este hecho, dado que ningún método puede ser implementado en una interfaz, todos los métodos en interfaz deben ser abstractos.

En cuarto lugar, la Interfaz solo puede incluir constantes como sus miembros de datos, lo que significa que deben ser finales y, por supuesto, finales las constantes se declaran como estáticas para mantener solo una instancia de ellas. Por lo tanto, static final también es una necesidad para las constantes de interfaz.

Así que en conclusión aunque usar métodos public abstract before y public static final before constantes de una interfaz es válido pero ya que no hay otras opciones se considera redundante y no se utiliza.

Evitaría poner modificadores que se aplican por defecto. Como se ha señalado, puede dar lugar a incoherencias y confusión.

Lo peor que vi es una interfaz con métodos declarados abstract...

Utilicé métodos declare con el modificador public, porque hace que el código sea más legible, especialmente con resaltado de sintaxis. En nuestro último proyecto, sin embargo, utilizamos Checkstyle que muestra una advertencia con la configuración predeterminada para los modificadores public en los métodos de la interfaz, así que cambié a ommitting ellos.

Así que no estoy muy seguro de lo que es mejor, pero una cosa que realmente no me gusta es usar public abstract en los métodos de interfaz. Eclipse hace esto a veces cuando refactoriza con " Extract Interfaz".

Siempre escribo lo que usaría si no hubiera interfaz y estuviera escribiendo una implementación directa, es decir, usaría public.

La razón por la que los métodos en las interfaces son por defecto públicos y abstractos me parece bastante lógica y obvia.

Un método en una interfaz es por defecto abstracto forzar a la clase implementadora a proporcionar una implementación y es público por defecto para que la clase implementadora tenga acceso para hacerlo.

Agregar esos modificadores en su código es redundante e inútil y solo puede llevar a la conclusión de que carece de conocimiento y/o comprensión de los fundamentos de Java.

Prefiero saltarlo, he leído en alguna parte que las interfaces son por defecto, public y abstract.

Para mi sorpresa, el libro - Head First Design Patterns, está usando public con declaración de interfaz y métodos de interfaz... eso me hizo repensar una vez más y aterricé en este post.

De todos modos, creo que la información redundante debe ser ignorada.

Con la introducción de private, static, default modificadores para los métodos de interfaz en Java 8/9, las cosas se complican más y tiendo a pensar que las declaraciones completas son más legibles (necesita Java 9 para compilar):

public interface MyInterface {

    //minimal
    int CONST00 = 0;
    void method00();
    static void method01() {}
    default void method02() {}
    private static void method03() {}
    private void method04() {}

    //full
    public static final int CONST10 = 0;
    public abstract void method10();
    public static void method11() {}
    public default void method12() {}
    private static void method13() {}
    private void method14() {}

}

Es totalmente subjetivo. Omito el modificador redundante public ya que parece un desorden. Como han mencionado otros, la coherencia es la clave de esta decisión.

Es interesante notar que los diseñadores del lenguaje C# decidieron hacer cumplir esto. Declarar un método de interfaz como público en C# es en realidad un error de compilación. La consistencia probablemente no es importante en todos los lenguajes, así que supongo que esto no es directamente relevante para Java.

La gente aprenderá tu interfaz completando el código en su IDE o en Javadoc, no leyendo el código fuente. Así que no tiene sentido poner "público" en la fuente - nadie está leyendo la fuente.