Is there a good reason to create really empty abstract class vs interface ?

Hypothetically, you might do this to ensure that there is a single common base class for future anticipated requirements ... or for some other reason.

But generally speaking it is a bad idea ... IMO.

(Of course, things like this often happen for historical reasons; e.g. the abstract class may have had more members in the past that have since been removed.)

From Stephen C's Answer

Resource Link: http://stackoverflow.com/a/10123241/2293534

From BalusC Answer:

The key is that you can extend from only one abstract class, while you can implement moreinterfaces.

Apparently the "empty abstract class" design desicion was made so that it prevents the implementing class from extending from another classes.

If it was me I'd let it go, otherwise it might break. Best is still to contact the original developers and ask for reasoning (and add them as comments in the abstract class for your and future convenience).

Marker Interface

An empty abstract class is very much equivalent to an interface except that it can extend a class

abstract class myAbstractClass // extends anotherClass implements anInterface
{

}

interface myInterface // extends anotherInterface
{

}

This pattern is called Marker interface