Although I've not come across a good use case yet for a (named) class inside an interface, I do occasionally use an anonymous class to provide a null implementation:Client code will often use this as a default value for a Foo:Using this null object pattern where you would otherwise use the null value tends to simplify your code, and also make it less prone to bugs (especially NullPointerExceptions if you forgot to stick in a null check somewhere).
I think that the general approach in Java for nested/inner types has been, they allow you to declare a class just about anywhere you could declare a variable, unless there's a particular reason you shouldn't be able to. They don't prevent you from doing it just because there's no particular positive reason to allow the usage. So nesting a class in an interface is allowed - why not? - even though it seems to be seldom useful.
One possible use for a nested class here is to define a new Exception type which is closely related to the interface, and generally useless to anyone not using hte interface. E.g.:
If you do have a class nested within an interface, it will be abstract since all interface members are implicitly abstract.
A class defined inside the Interface is not a member method of the class. The statement is true only for interface methods, not for any declaration or interface fields (for e.g. interface fields are not abstract).
Here is an example:
You could call the methods as too.
How you use this feature at your work, depends on the design of the system.