wood burning stoves 2.0*
The moose likes Java in General and the fly likes regarding marker interfaces Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "regarding marker interfaces" Watch "regarding marker interfaces" New topic
Author

regarding marker interfaces

Saral Saxena
Ranch Hand

Joined: Apr 22, 2011
Posts: 202

Hi Folks,

Can you explain me in detail about the speciality of marker interface, I was going through that in which techinically it sataes that there are no more methods...but then at the behind the scenes how does it work..!!marker interface like serializable ,colenable how do they work behind the scenes..??
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42360
    
  64
Please use the "Search" link at the top of the page to find the many, many previous discussions on this topic. At this point, I don't think anything more can usefully be said about this.


Ping & DNS - my free Android networking tools app
Rahul Bansode
Greenhorn

Joined: Nov 03, 2011
Posts: 18
I know what is marker interface - An interface with no methods. Example: Serializable, Remote, Cloneable.

I googled for the same long ago , and Got something

Basically it is just to identify the special objects from normal objects. Like in case of serialization , objects that need to be serialized must implement serializable interface and down the line writeObject() method must be checking somewhere if it is a instance of serializable or not. As far as i think ,Thats the only purpose for which writeObject is using interface serializable(marker interface). Right? or jvm provides some extra functionality too on the basis of serializable interface?

Similar kind of logic is true for cloneable interface.

Now lets see how it is useful.

Lets say in a application we have 1000 value objects.We want to serialize only 100 specific objects . Now JDK has said that programmer role is just to mark the object as special with marker interface in this case its serializable interface.Now JDK will take care of that which object to serialize or not?

Yes we could achieve this kind of behaviour with some kind of bollean flag . but that would be a bad approach.

Similarily we can say in case of user defined marker interface , we can distinguish special objects with help of marker interface.Like we can use instance of operator to determine if it is a instance of that particular interface . If yes proceed in case of No throw some exception.












Rahul Bansode
Greenhorn

Joined: Nov 03, 2011
Posts: 18
This is with the example ...


A marker interface lacks method declarations, and so specifies behaviour through other means (e.g., documentation), and expects implementing classes to implement that behaviour.

It is essentially used to convey metadata about a class. Nowadays, we have annotations for that.

The specific functionalities you mention in your post belong to specific marker interfaces, like perhaps java.io.Serializable. Some marker interfaces are "special" in that the language and the JVM grant special considerations for them. I think in general, however, marker interfaces are just sloppy interfaces.

Contrived example:



UnverifiedIdentity is the marker interface. It conveys the metadata that a given Identity object is unverified.</object>
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8043
    
  22

Rahul Bansode wrote:I think in general, however, marker interfaces are just sloppy interfaces.

I disagree. While it's true that one of them (Cloneable) is arguably the worst mistake made by the original design gang, I have no problem with marker interfaces in general; and I completely disagree that they can or should be replaced with annotations.

Interfaces describe a contract for behaviour, and just because that behaviour can't be related to a set of methods doesn't mean that the interface has no value.
The main problems I see with marker interfaces is that
(a) They don't describe a type.
(b) They can be easily forgotten. RandomAccess, for example, is extremely useful in certain situations; but I know quite a few fairly experienced programmers who either aren't aware of it, or who forgot it existed. This means that it really only has meaning in a positive context, or when used in conjunction with classes in java.util: A user-defined List that implements it can be assumed to have good direct access capability; one that doesn't can't be assumed not to.

Don't throw the baby out with the bath-water.

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3647
    
  17

I disagree with you Winston. Marker interfaces are only necessary to fix stuff when you've already released software with a flawed design. Marker interfaces force code that uses them into dynamic typing.

Cloneable and Serializable are evil. RandomAccess should have been unnecessary. Instead, the List interface should have had something like an "isRandomAccess()" method. Now it's too late.

Behavior *always* comes with methods. You should not describe behavior if you can not specify to what methods the behavior pertains.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8043
    
  22

Stephan van Hulst wrote:...Marker interfaces are only necessary to fix stuff when you've already released software with a flawed design. Marker interfaces force code that uses them into dynamic typing.
Cloneable and Serializable are evil. RandomAccess should have been unnecessary. Instead, the List interface should have had something like an "isRandomAccess()" method. Now it's too late.
Behavior *always* comes with methods. You should not describe behavior if you can not specify to what methods the behavior pertains.

I get your point, and I agree with you in principle; however, software design is not (yet?) a perfect science, and languages compound the flaws with their limitations. Also, as we both know, it is virtually impossible to change an interface after its public release.

You call a construct like 'x instanceof RandomAccess' dynamic typing; in the case of a marker interface I call it the equivalent of calling a method that returns a boolean. And while I do agree that it would have been better if the method had been in List to begin with, I certainly think that a marker interface is a lesser evil than an annotation (or indeed endless subtypings of existing interfaces). Furthermore, we will probably never get rid of dynamic typing completely, as it is required by every equals() method ever written.

One last point is that having a marker interface allows me to define generic methods that have compile-time safety, viz:
public static final <T extends List & RandomAccess> void fastSort(T list) {...

In the specific case of RandomAccess, I also think it would have been MUCH better for it to have been added as part of the List interface, because it would then be more difficult to forget.

Fun discussion though .

Winston

Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3647
    
  17

Definitely agree about annotations. They should never affect the program's control flow, IMO. They should only be used for tools dealing with an annotated program.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8043
    
  22

Stephan van Hulst wrote:Behavior *always* comes with methods. You should not describe behavior if you can not specify to what methods the behavior pertains.

I've decided. 'Took me a while, and I did have to think a lot about it (we had the same teachers, I suspect), but I disagree with that statement (see below).

For me, RandomAccess describes the characteristics of a randomly accessible List perfectly (at least in Java).
In fact, I'll go further: any interface that can be subdivided into two (and only two) distinct behaviours that cannot be defined by methods should use a marker interface.
(I expect lots of arguments about this ).

Why:
1. It's simple.
2. It's secure (a public interface can't be changed).
3. It's documentable.

Now to get back to why I disagree with with Stephan's statement: RandomAccess is a great example of behaviour that cannot be defined by method: Random access performance.
A List that exhibiits good random-access performance is indistinguishable from any other List until you time its get() method. And so it should be. Data structures should not be concerned with how they are used; only with being correct.

Yes, an isRandomAccess() method that indicates a specialization (not known to List) could have been manufactured, but to what end?
It's a flag, pure and simple; and furthermore it indicates a subtype with no distinguishing characteristics beyond its type.

But it is, most assuredly, a type - as you will find out if you ever try to sort a million-element LinkedList.

In fact, it wouldn't surprise me in the slightest if Collections.sort() doesn't use RandomAccess to decide how to do its sort.

Winston
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: regarding marker interfaces