Methods are also declared in interfaces. A method declared in an interface does not define the actual behavior of the method; they do not contain the code. They have only the head of the method; in other words, they are abstract implicitly. Although nobody does, you may even use the abstract keyword in an interface when you define a method.

Interfaces look very similar to classes, but instead of using the class keyword, we use the interface keyword. Because interfaces are mainly used to define methods, the methods are public if no modifier is used.

Interfaces can also define fields, but since interfaces cannot have instances (only implementing classes can have instances), these fields are all static and they also have to be final. This is the default for fields in interfaces, thus we do not need to write these if we defined fields in interfaces.

Interfaces can also have nested classes, but they cannot have inner classes. The obvious reason for that is that inner class instances have a reference to an instance of the enclosing class. In the case of an interface, there are no instances, so an inner class could not have a reference to an instance of an enclosing interface, because that just does not exist. The joyful part of it is that we do not need to use the static keyword in the case of nested classes because that is the default, just as in the case of fields.

With the advent of Java 8, you can also have default methods in interfaces that provide default implementation of the method for the classes that implement the interface. There can also be static and private methods in interfaces since Java 9.

Methods are identified by their name and the argument list. You can reuse a name for a method and have different argument types; Java will identify which method to use based on the types of the actual arguments. This is called method overloading. Usually, it is easy to tell which method you call, but when there are types that extend each other, the situation becomes more complex. The standard defines very precise rules for the actual selection of the method that the compiler follows, so there is no ambiguity. However, fellow programmers who read the code may misinterpret overloaded methods or, at least, will have hard time identifying which method is actually called. Method overloading may also hinder backward compatibility when you want to extend your class. The general advice is to think twice before creating overloaded methods. They are lucrative, but may sometimes be costly.