Silent Death Of The Classic Marker Interface Pattern - Is java.io.Serializable Legacy?

I was in the process of thinking about @Stateless and JPA and Serializable (needed some examples for my book...) and noticed, that actually one of the GoF patterns siltently died - or at least its realization / implementation was completely refactored. The Marker Interface pattern was used to enhance a class with additional type to change its behavior or introduce some priviliged actions. A prominent example are java.io.Serializable and java.rmi.Remote interfaces. Both were introduced because of security reasons. Only classes which implement those interfaces are able to be flushed to  disc or transfered over the network.

With the advent of annotations the approach of implementing an interface is actually no more appropriate. The usage of annotations @Serializable or @Remote would be much more elegant. There is an example in JSR-181, where an endpoint has only to be annotated with @WebServce annotation - no additional interface realization is necessary.

Using an annotation is not the same as implementing an interface, because the type of the class is not going to be extended. Nonetheless, the same effect can be achieved. So the infrastructure has no more to check the type (e.g. with instanceof), but has to check the existence of the annotaition via reflection (class#getAnnotation) instead.

So java.io.Serializable and java.rmi.Remote are actually legacy...

Comments:

True, I have not thought about that before.

Should for the check not rather the isAnnotationPresent method be used?

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#isAnnotationPresent(java.lang.Class)

Posted by Andreas Ebbert-Karroum on September 02, 2008 at 04:10 PM CEST #

Andreas,

absolutely - is cleaner. Thank you very much!
Sorry - but I hacked this entry in few minutes...

adam

Posted by Adam Bien on September 02, 2008 at 04:32 PM CEST #

True, but that type information is still useful if you need static compiler checks, e.g. if a reference to a certain class is allowable in a certain point. Of course this is not the case for everything, e.g. I don't see a reason for which one would want a static compiler check on a webservice or a remote interface (but sometimes I could see the utility of statically checking a Serializable).

Posted by Fabrizio Giudici on September 03, 2008 at 02:22 PM CEST #

Fabrizio,

you are right. But the funny story is: even ObjectOutputStream, ObjectInputStream work with java.lang.Object and not java.io.Serializable...

void writeObject(Object obj) [http://java.sun.com/javase/6/docs/api/java/io/ObjectOutputStream.html#writeObject(java.lang.Object)]

thank you fabrizio!,

adam

Posted by Adam Bien on September 03, 2008 at 02:53 PM CEST #

Problems is: some frameworks requires the objects to "implements Serializable". Like GWT, for example, you can't use transfer objects between your service and the web GUI implemented with GWT without that.. Completely agree with you that annotations are more modern approach, but for some time I guess we will be forced to keep the plain old interfaces around..

Posted by Felipe Gaúcho on September 03, 2008 at 03:04 PM CEST #

Good post! Just to let you know that the @WebService annotation has a typo (it's written @WebServce) :)

Posted by Marcio Aguiar on September 03, 2008 at 10:58 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments
License