Over a million developers have joined DZone.

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

DZone's Guide to

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

· Java Zone ·
Free Resource

Distribute microservices between the private and public clusters, yet maintain bi-directional connectivity. Content provided by IBM Developer.

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 has been completely refactored. The Marker Interface pattern was used to enhance a class with an additional type to change its behavior or introduce some priviliged actions. Prominent examples 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 whereby you implement an interface is actually no longer appropriate. The usage of annotations @Serializable or @Remote is much more elegant. There is an example of this in JSR-181, where an endpoint has only to be annotated with the @WebServce annotation. No additional interface realization/implementation 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 no longer needs to check the type (e.g., with instanceof), but has to check the existence of the annotation via reflection (class#getAnnotation or isAnnotationPresent) instead.

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

From http://www.adam-bien.com/roller/abien/

Use this tool to look at the contents of GitHub and classify code based on the programming language used.  Content provided by IBM Developer.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}