Are "public" and "public final" redundant for interface fields?

You cannot have a final method declared in an interface. Fields are always final but methods are always abstract (and never final). You cannot define an interface method that is to be implemented only by classes in the same package.^* From section 9.3 of the Java Language Specification:

Every field declaration in the body of an interface is implicitly public, static, and final. It is permitted to redundantly specify any or all of these modifiers for such fields.

and from section 9.4:

Every method declaration in the body of an interface is implicitly public (§6.6).

Every method declaration in the body of an interface is implicitly abstract, so its body is always represented by a semicolon, not a block.

It is permitted, but discouraged as a matter of style, to redundantly specify the public and/or abstract modifier for a method declared in an interface.

^* As Paul Bellora points out in a comment, you can make the interface itself package-private (or protected, or even private) if you want to restrict its visibility.

Are “public” and “public final” redundant for interface methods?

Yes.

All methods in an interface are implicitly public and abstract (but not final).

All fields in an interface are implicitly public, static and final.

The JLS states this. It also states that these modifiers can be left out.

---

Why? Well there are a variety of reasons:

• Fields and methods are implicitly public because the point of an interface is to declare an ... interface that other classes can see. (If you want / need to restrict access, this is done via an access modifier on the interface itself.)

• Fields are static because if they were not you would be declaring visible instance fields on an object ... and that's bad for encapsulation.

• Fields are final because non-final fields would be another way of declaring public static fields ... which are terrible from an OO perspective.

• Methods are abstract because allowing method bodies would effectively turn interfaces into abstract classes.

Another reason for making methods abstract and fields static in an interface is that if they didn't, diamond inheritance, and inheritance of a method from two distinct interfaces would both be problematic.

But either way, this is how Java is defined, so the questions are moot ... unless you are thinking of inventing your own programming language.

Note that in Java 8, you can declare methods in an interface, using the default modifier. And in Java 9, you can declare private methods, in some cases. But use of the public keyword is still redundant.

---

Why should I remove them?

You don't have to remove them. The Java compiler doesn't care. You can remove them, but you don't have to remove them, unless you are trying to conform to some Java style guidelines that insist on this. Your code will probably be more readable if you are consistent, but you could make it consistent by using the redundant modifiers everywhere; e.g. adding them rather than removing them.

Doesn't it mean that I want add method be implemented by whatever class while remove method implemented only by classes of my same package?

No it doesn't mean that. Or at least, it might mean that to you, but it won't mean that to the Java compiler, other Java tools ... or other people reading and maintaining your code. IMO, it would be ill-advised to place any meaning on the presence or absence of redundant keywords.

• Interfaces by definition are abstract so the abstract modifier on the interface is redundant.
• Variables in interfaces and annotations are automatically public, static and final, so these modifiers are redundant as well.
• As annotations are a form of interface, their fields are also automatically public, static and final just as their annotation fields are automatically public and abstract.
• Final classes by definition cannot be extended so the final modifier on the method of a final class is redundant.

reading this: http://checkstyle.sourceforge.net/config_modifier.html