When there is nothing to implement in the marker interfaces like Serializable . . what is the use of implementing it?
It indicates that the class (and consequently all the fields which aren't transient) are candidates for serialisation. And if you're building a framework reliant on serialisation, you can of course write a method thus:
public void registerObject(Serializable obj);
to limit the classes you're prepared to accept.
Because a serialized object needs to retain compatibility across systems, serialisation is an explicit design decision and hence requires the use of the marker interface, to identify such candidates.
There's also a security aspect. You don't want to make everything serialisable - otherwise you can accidentally expose (say) passwords or other sensitive data via serialisation.
Such marker interfaces are useful in the case other code takes decisions depending on whether an object implements some marker interface.
In the case of Serializable
, reflection will be used to serialize the fields of the objects.
Now annotations are preferred as they don't propagate to sub-classes.
They are called marker interfaces. And as the name implies, they mark that some object is available for certain sort of operations.
Serializable
means that the object is eligible for java serialization, for example.
It has been discussed whether they shouldn't be replaced by annotations, since their functions are quite similar.
In earlier versions of Java, Marker Interfaces were the only way to declare metadata about a class. For example, the Serializable Marker Interface lets the author of a class say that their class will behave correctly when serialized and deserialized.
In modern Java, marker interfaces have no place. They can be completely replace by Annotations, which allow for a very flexible metadata capability. If you have information about a class, and that information never changes, then annotations are a very useful way to represent it.
If you implement an interface then instanceof
will be true. If you interface has nothing to implement then you can use this to mark a class with meta-data like annotations do for Java 1.5 and up without having to force the implementor to do anything special.
You are right in reasoning that an empty interface does not affect the "standard" execution of the program which is based on inspection/mutation of fields and dispatching of methods.
However, marker interface are useful when used in conjunction with reflection: A library/method inspects (via reflection) an object and works differently if its class impplements the marker interface. As of Java5 there's very little need for marker interfaces - the same "marking" facility can be achieved via Java annotations - which (again) most of their effect will be achieved via reflection-based code.
I don't think this is really a Java question, so I'll speak to marker interfaces. One case I use marker interfaces is as a tool to create strongly typed API's have as much help from the compiler as possible. For example: (This example is silly to be sure as it would never make sense to do this in the real world, but for now I can't think of something actually relevant. It'll make the point nevertheless.)
interface Number { ... }
interface Zero extends Number { ... }
interface NonZero extends Number { ... }
Let's assume Zero and NonZero is a marker. Now I can have the compiler prevent a Divide-By-Zero runtime exception. Instead of
Number divide(Number dividend, Number divisor) { ... }
I can write
NonZero divide(Number dividend, NonZero divisor) { ... }
Now, if I had a language like say Scala, I can sugarize this quite nicely via a DSL (using Implicits) removing the verbosity.
Again, this is only one use case for markers.