Marker Interfaces: Runtime vs compile time errors

Question

So reading upon the marker interface concept in Java, it kind of does not feel right to me, mostly because I am involved in writing applications where it is a disaster for the program to experience run time errors.

In terms of design when I can avoid a run time error by using for example a abstract class why would I use a marker interface where I have a risk of run time errors.

I have always thought that I will avoid run time errors even though I may restrict the code by producing compile time errors.

Wouldn't marker interfaces cause higher risk of failures especially when more and more developers won't really read every line of documentation there is(Not me, I am one of the good guys)

Maybe its just the C++ in my head talking, but are there any advantages of designing it this way?

Answer 1

Marker Interfaces were the only way to declare metadata about a class in early versions of Java eg Serializable says the implementing class will behave correctly when serialize/deserialize will be called.

Today Marker interfaces feel to me a bit redundant (or outdated) as they can be replaced by Annotations that allow to describe class metadata in a very flexible way.

Just found a quote from Joshua Bloch...

You may hear it said that marker annotations (Item 35) make marker interfaces obsolete. This assertion is incorrect. Marker interfaces have two advantages over marker annotations. First and foremost, marker interfaces define a type that is implemented by instances of the marked class; marker annotations do not. The existence of this type allows you to catch errors at compile time that you couldn't catch until runtime if you used a marker annotation.