Generally, yes. However, you must be aware of surprises, some of which I mention next.

Disclaimer: none of these lists is exhaustive.

Badly designed interfaces:

1. with lots of methods;
2. with methods that don’t throw sensible exception types, or methods that don’t throw at all (a problem in checked exception languages like Java: when not given a second thought, most people usually throw Exception or nothing);
3. with methods that may not be implemented, in the sense that they can throw UnsupportedOperationException (an unchecked exception) or a subclass of it (in .NET, there’s already a more explicit NotImplementedException); usually seen together with huge interfaces.

What can be done:

1. Split the huge interfaces;
2. Provide at least one subclass of Exception in the same namespace as the interface;
3. If you cannot split an interface for some good reason, state clearly which methods may throw a UnsupportedOperationException (or NotImplementedException in .NET). It may be all methods, but state it clearly, such as at the head of the interface’s documentation or in a separate small paragraph near the top, and also in each method’s description.

If you must use a huge interface which describes what methods may throw unchecked exceptions such as UnsupportedOperationException (I’m assuming it’s an interface out of your control), be ready to catch them or document that your methods may throw them.

An interface should be as small as possible and its implementation should mean it’s totally implemented. In the real world, however, it’s not always the case, and sometimes one has to go through hoops.

A bad class implementation:

1. that implements an interface on the interest of supporting only part of its contract, like one or two of its methods, usually doing nothing or returning non-sense for all other methods (unless it’s actually implementing an observer);
2. that throws UnsupportedOperationException (or NotImplementedException in .NET) in methods where the interface doesn’t clearly state that it may be thrown;

What can be done:

1. Have an abstract class that implements most boilerplate, and either inherit from it directly, or create a subclass of it and use this new class to instantiate delegation objects. In fact, many Java observer objects already come with this facility, even though the default implementation of all its methods is to do absolutely nothing.
2. Correct it, follow the contract. If the code is not yours, try to wrap such misbehaviour.

Does this mean that interface inheritance is always safe? Or there are guidlines for interface inheritance?

No; you should always be careful of how you design the interface and what contracts does it enforce on the implementing classes. In Java you are obliged to implement all of the interface’s methods and maybe you really don’t need all of them in your class and you cannot change the interface either.

For example you have a large interface with numerous methods that clearly does not respect Interface Segregation Principle. If you choose to implement this interface but in your class you only need less than half of the interface’s methods, then using interface inheritance is not a good idea.

Interfaces should be quite sparse and limited to the methods required. As long as the Interface is well designed is it safe to inherit from it.

That being said it is possible to create huge interfaces with lots of methods which are not required for the interface. While it is safe to inherit from them, it it not recommended.

Designing an Interface requires careful thought as once it is being used it can be costly to modify. Changing the interface is difficult once it has been used. Adding methods or changing their signature requires doing the same to all inheritors. Removing methods is more difficult as the methods may include functionality of the inheritor, in which case they must be retrained or reworked, otherwise they should removed.