Refusal to use marker interface as parameter?
Heya all,
I've seen a lot of professional (ie Apache, Sun, etc) Java code that has code similar to this:
publicvoid serialise(Object o)
{
if (oinstanceof Serializable)
thrownew IllegalArgumentException("Object is not serializable");
... code here...
}
Whereas surely it could be re-written as:
publicvoid serialise(Serializable o)
{
... code here...
}
Thus giving us compile-time type safety. I seem to get the impression that 'Serializable' and 'Cloneable' and other such 'marker' interfaces shouldn't be used as parameters in this way because they are not 'real' interfaces as such. I usually prefer the second form; but I have seen both forms fairly commonly.
Any comments/suggestions on when it's better to use different ways?
[1229 byte] By [
alanpza] at [2007-10-2 7:58:57]
If you are overriding a method then that would be one case where you couldn't make it more explicit.
IMO, I agree that the second form is more explicit. It is, however, a bone fide interface, albeit one with no variables or methods. BTW, I think you meant to use instanceof and evaluate a false, rather than a true, comparison in your method.- Saish
Saisha at 2007-7-16 21:50:07 >
> IMO, I agree that the second form is more explicit.
> It is, however, a bone fide interface, albeit one
> e with no variables or methods.
>
> BTW, I think you meant to use instanceof and evaluate
> a false, rather than a true, comparison in your
> method.
>
> - Saish
the error in what was propsed by op is so obvious, and yet you didnt get it...
Saisha at 2007-7-16 21:50:07 >
> If you are overriding a method then that would be one> case where you couldn't make it more explicit.and that would be a silly mistake.
Saisha at 2007-7-16 21:50:07 >
Then allow me to be more specific, without retracting my original point. The following methods within java.io.ObjectInputStream and java.io.ObjectOutputStream which current exist as:
public Object readObject() throws IOException {}
public void writeObject(Object object) throws IOException {}
Could easily be re-written (and be more specific and type-safe) via the following declarations:
public Serializable readObject() throws IOException{}
public void writeObject(final Serializable object) throws IOException {}
I would further propose renaming then SerializableInputStream and SerializableOutputStream, as they do not truly take all instances of java.lang.Object.
- Saish
Saisha at 2007-7-16 21:50:07 >
saish:thats not type safe, thats a stupid mistake. please wake up, you are hurting me...
Saisha at 2007-7-16 21:50:07 >
DaFei, I will entertain your ramblings only briefly in this thread. Given that readObject() and writeObject() require the object passed in to be an instance of java.io.Serializable, in all implementations of Java serialization from JDK 1.1 and onward, then a method requiring a Serializable object in its signature or as its return value is more type-safe than java.lang.Object. Plain and simple.
- Saish
Saisha at 2007-7-16 21:50:07 >
Or to put it another way, this change would allow compile-time detection of serialization errors rather than run-time. And assuming compiler overhead (or development) is not an overriding cause, compile-time detection of errors is better than run-time detection of errors.- Saish
Saisha at 2007-7-16 21:50:07 >
And because I know you will immediately get confused with generics, both classes and interfaces (even in 1.4 and prior) are types.- Saish
Saisha at 2007-7-16 21:50:07 >
Saish
serizble is only a marker, implementing this interface does not mean the class is abslutely serilizable, which in other words, errors canot be caught at compile time. it is a matter of runtime isue anyway. eg, yu may throw in something that is not serilizable qnd causes troubles in runtime. so it is better to save some time at compile tme.
also, keep in mind, that methos writed things in super classes too.
Saisha at 2007-7-16 21:50:07 >
The same argument could be made of the 'final' keyword applied to, say, Collections. This does not mitigate the utility of the 'fina'l keyword's safety in ensuring the reference to the Collection does not change.
And the compiler overhead in checking whether a given Object implements Serializable (presumably a pre-requisite to calling a serializable method) is negligible.
- Saish
Saisha at 2007-7-16 21:50:07 >
But your point is fair. It would be compiler overhead to recursively descent all object types in a given object (and its superclass hierarchy) to determine that all are Serializable. However, in fairness, I did not advocate that a compiler go to such lengths. Just because a benefit is incremental rather than total does not mean it does not offer value.
- Saish
Saisha at 2007-7-16 21:50:07 >
Wow, I didn't know daFei the 'finally block is just syntactic sugar for you fish-brained people' was still around!
Surely this change couldn't break any code that wasn't already broken.
Yes, it would mean casting Objects you intend to write to Serializeable before calling the method, but how many pointers of type Object are lying around anyway?
My vote is to add it to the bug-parade, and God-speed to you.
~Cheers
> Wow, I didn't know daFei the 'finally block is just> syntactic sugar for you fish-brained people' was> still around!glad you sre still around too, antime:)
at 2007-7-20 19:33:42 >
> But your point is fair. It would be compiler
> overhead to recursively descent all object types in a
> given object (and its superclass hierarchy) to
> determine that all are Serializable. However, in
> fairness, I did not advocate that a compiler go to
> such lengths. Just because a benefit is incremental
> rather than total does not mean it does not offer
> value.
>
> - Saish
non of the interfaces defined types, not just markers, should be used that way. interfaces are for the sole purpose of contracting among different emtities, they are always a runtime thing, and should be treated that way.
at 2007-7-20 19:33:42 >
Where an object implements an interface or not can definitely be determined at compile time. Reflection would be the only run-time circumstance that I could envision.- Saish
Saisha at 2007-7-20 19:33:42 >
> Where an object implements an interface or not can
> definitely be determined at compile time. Reflection
> would be the only run-time circumstance that I could
> envision.
>
> - Saish
it is not a matter of a compiler's capability of detecting an interface, (it certainly can), it is a matter of a compiler's capability of enforcing the implementations of the interface on the class that inplementing the interface. as the compiler can not do that, it is a waste, this is particularly true with empty interfaces, markers.
Saisha at 2007-7-20 19:33:42 >
The compiler will enforce that an implementing class of an interface provides concrete implementations of all interface abstract methods. This much is defined by the JLS. However, if I understand your assertion correctly, you are saying that because marker interfaces have no abstract methods defined, the compiler will not enforce any concrete implementing methods on implementing classes, and hence the value of marker interfaces is less. As this is a totally subjective opinion, I cannot really argue. Except perhaps to pose the question a different way. Would an interface with seven abstract methods therefore be more useful than an interface with three? Presumably, the compiler is enforcing even more concrete methods on an implementor here.
Finally, though I do not do this myself, I could see using marker interfaces as annotations (say, in JDK 1.4 and earlier prior to actual annotations). One could implement ModelObject, Singleton, SessionFacade, etc. Of course, there would be no methods, but there would be utility. Javadocs, for instance, would show that a class implements Singleton (even though this is a design pattern and not an abstract method). Again, I do not personally do this and would advocate annotations in 1.5 for this purpose.
- Saish
Saisha at 2007-7-20 19:33:42 >
> The compiler will enforce that an implementing class
> of an interface provides concrete implementations of
> all interface abstract methods. This much is defined
> by the JLS. However, if I understand your assertion
> correctly, you are saying that because marker
> interfaces have no abstract methods defined, the
> compiler will not enforce any concrete implementing
> methods on implementing classes, and hence the value
> of marker interfaces is less. As this is a totally
> subjective opinion, I cannot really argue. Except
> perhaps to pose the question a different way. Would
> an interface with seven abstract methods therefore be
> more useful than an interface with three?
> Presumably, the compiler is enforcing even more
> e concrete methods on an implementor here.
>
> Finally, though I do not do this myself, I could see
> using marker interfaces as annotations (say, in JDK
> 1.4 and earlier prior to actual annotations). One
> could implement ModelObject, Singleton,
> SessionFacade, etc. Of course, there would be no
> methods, but there would be utility. Javadocs, for
> instance, would show that a class implements
> Singleton (even though this is a design pattern and
> not an abstract method). Again, I do not personally
> do this and would advocate annotations in 1.5 for
> this purpose.
>
> - Saish
interfaces add no value to an object, markers or not dont matter. the compiler could only superficially make sure a class implements the specifications, but not the actual details in implementations, and an implementation could be emty. what the compiler cannot do matters in runtime.
stuck with webspehere 1.3 and 1.4 at work, i dont know much about java 5 annotations but am starting on this in my eclipse 3.11 with java 5...
Saisha at 2007-7-20 19:33:42 >
>
> interfaces add no value to an object, markers or not
> dont matter. the compiler could only superficially
> make sure a class implements the specifications, but
> not the actual details in implementations, and an
> implementation could be emty. what the compiler
> cannot do matters in runtime.
>
Interfaces are checked at runtime even if they are only markers.
