That is not exactly nice style. But you can instantiate the inner class by accessing it with the qualified name. As the "outer" is an interface, you don't even need an instance implementing Xinterf.
Why to do such? If it is a non-static inner class (which is not possible in an interface) then you can only build an instance by using an object of the outer. The inner object then is bound to the outer object and can access it's internals. Can be handy sometimes if you need to give out an object that can do such but you don't want to open your outer class (you can easily implement the flyweight pattern this way). But when the inner class is static or within an interface, it is "only" like a namespace. You know where to find the class, but it is not directly in a package but a level below. Not very clean.
It is legal within the language specifications so some people will use it. So you need to know about it because you may encounter it in foreign code.
is there any special purpose to use...or just like that
De-facto "static" inner classes in interface? - No. It is a way to circumvent the lack of namespaces in Java or the restriction that you can only put one public class into one compilation unit.
Non-static inner classes have some use. Take for example this (in itself not terrible useful) example:
You can hand out accessors to the inner data without exposing the inner data, without providing access methods within your outer object, without the need to hand around the outer object. Gets especially useful when the inner class implements some interface that may be needed by some other class. I used this pattern with TreeNodes quite a lot, where your data structure is independent from the interfaces you need to implement the view, but you still have OO designs and encapsulation.
You can thank my dental hygienist for my untimely aliveness. So tiny: