This week's book giveaway is in the Agile and other Processes forum. We're giving away four copies of The Mikado Method and have Ola Ellnestam and Daniel Brolund on-line! See this thread for details.
If an interface has no direct superinterfaces, then the interface implicitly declares a public abstract member method m with signature ss, return type rr, and throws clause t corresponding to each public instance method mm with signature ss, return type rr, and throws clause tt declared in Object, unless a method with the same signature, same return type, and a compatible throws clause is explicitly declared by the interface. It is a compile-time error if the interface explicitly declares such a method m in the case where m is declared to be final in Object.
Seetharaman Venkatasamy wrote:I do call it as a Mixin instead of Marker...
That's not standard usage, though. In languages that have proper mixins (and that doesn't include Java) they aren't the equivalent of marker interfaces. In fact, a mixin contains implementation, as well as defined methods.
Kumaravadivel Subramani wrote:Marker interface doesn't have any methods in it and it simply tells the JVM what to do. you could also create marker interface to do some process.
Actually it doesn't do anything, JVM or otherwise. It is exactly what it says: a marker (or flag) that your program can check (using instanceof) to see if an object has a particular characteristic or not.
The best example I know is RandomAccess, which is supposed to be implemented by Lists that exhibit good (usually O(1), but certainly better than O(n)) "get element n" performance.
If you look at ArrayList, you'll notice that it implements it, whereas LinkedList doesn't.
HIH
Winston
[Edit] BTW, java.lang.Cloneablelooks like a Marker interface, but actually isn't. In fact, it's a bit of an aberration, and (hopefully) never to be repeated.
Isn't it funny how there's always time and money enough to do it WRONG?
Winston Gutkowski wrote:
[Edit] BTW, java.lang.Cloneablelooks like a Marker interface, but actually isn't. In fact, it's a bit of an aberration, and (hopefully) never to be repeated.
Yeap, used a wrong word over there as "JVM" instead of java libraries which does a specific job when any type implements this marker interface type. Thanks for correcting me.
Winston Gutkowski wrote:
[Edit] BTW, java.lang.Cloneablelooks like a Marker interface, but actually isn't. In fact, it's a bit of an aberration, and (hopefully) never to be repeated.
How do you figure it's not?
Because
(a) It does do something.
(b) It requires the programmer to implement a clone() method in order to work properly.
(c) It is not used like one. When was the last time you wrote
if (someObject instanceof Cloneable) ...
I suppose you could argue semantically that it is one for the Object class, but in my view it was just a bad day at the office for the designer.
I'd argue the same about Serializable: looks like a duck, but don't quack like one.
Winston Gutkowski wrote:
[Edit] BTW, java.lang.Cloneablelooks like a Marker interface, but actually isn't. In fact, it's a bit of an aberration, and (hopefully) never to be repeated.
How do you figure it's not?
Because
(a) It does do something.
That's a runtime issue.
(b) It requires the programmer to implement a clone() method.
No it doesn't.
(c) It is not used like one. When was the last time you wrote
if (someObject instanceof Cloneable) ...
I don't, but the JVM does.
I always figured what makes a marker interface is simply one that doesn't declare any methods, so implementing it is not carries no compile-time requirements, and it's mainly used at runtime in an instanceof check. The fact that I don't personally do the instanceof check in my code, or that the result of it failing is an exception (as opposed to, say, choosing some other object or some other access method, as with RandomAccess), doesn't make it less of a marker interface.
Unless I've missed an official definition somewhere, which is certainly possible.
Tim Moores
Rancher
Joined: Sep 21, 2011
Posts: 2407
posted
0
Cloneable is not such a good example, as it arguably should contain the clone method. Sun's class library designers weren't perfect :-)
I'd still argue that that's a pretty weird example (in fact, the whole interface is a bit weird), and that Cloneable is not what I'd consider a Marker interface.
Winston Gutkowski wrote:and that Cloneable is not what I'd consider a Marker interface.
It occurred to me that maybe I should say what I do consider an MI.
To me, it's an interface that can be used to implement a strategy. For example, if I want to sort or shuffle a List, I can be pretty sure that if it implements RandomAccess, I will be able to swap elements pretty quickly, whereas if it doesn't it's probably best to do a copy, sort and reload.
If you know something's Cloneable, or Serializable, what do you know? It's unlikely that you could use the information in any effective way.
Winston Gutkowski wrote:
If you know something's Cloneable, or Serializable, what do you know? It's unlikely that you could use the information in any effective way.
Sorry to flog and expired equine, but again, just because it's not my code that's using that information to make a decision, I don't see why that makes a difference.
Matthew Brown wrote:I'd agree with Jeff. Just because a marker interface was a bad choice of design doesn't mean it's not a marker interface.
Seems I'm outvoted.
BTW, I clicked on the 'Report' icon by accident (I knew it would happen sooner or later). I hope it didn't cause any ripples.
Any chance it could be moved to the left hand side of the window?