Adam Bien's Weblog
- Alle
- General
- Blog Statistics
- Publications
- Netbeans
- RIA / Java FX
- Fun
- Enterprise Architekturen, Leitfaden für Effiziente Softwareentwicklung
- Java / JEE / Architecture
- Java EE 5 Architectures And Idioms
- Productive Java EE - Rethinking Best Practices
- Events
- In The Clouds
- Java EE 5 Architectures
- JavaONE 2007
- JavaONE 2009
- Real World Java EE Patterns - Rethinking Best Practices
- JavaONE 2008
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...
Posted at 12:56PM Sep 02, 2008 by Adam Bien in Java EE 5 Architectures And Idioms | Kommentare[6]
[my tweets] 
Rss My book: Real World Java EE - Rethinking Best Practices
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)
Gesendet von Andreas Ebbert-Karroum am September 02, 2008 at 02:10 PM CEST #
Andreas,
absolutely - is cleaner. Thank you very much!
Sorry - but I hacked this entry in few minutes...
adam
Gesendet von Adam Bien am September 02, 2008 at 02: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).
Gesendet von Fabrizio Giudici am September 03, 2008 at 12: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
Gesendet von Adam Bien am September 03, 2008 at 12: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..
Gesendet von Felipe Gaúcho am September 03, 2008 at 01:04 PM CEST #
Good post! Just to let you know that the @WebService annotation has a typo (it's written @WebServce) :)
Gesendet von Marcio Aguiar am September 03, 2008 at 08:58 PM CEST #