The NonTransportable Transportable
-
In Java, the Serializable marker interface lets the jvm know that the object can be implicitly [de]serialized by the jvm at opposing ends of some transport as long as both were part of the same compilation. There is the optional special member of an object that implements Serializable: long serialVersionUID, which tells the underlying jvm that as long as that value is the same in the compilation units on both sides of the transport, that the known fields on both ends can be processed, even though the two java files may have been compiled at different times.
I give you:
public class NonTransportable_Transportable_Class implements Serializable {// WARNING: This MUST be changed for EVERY compilation - source changed by ant!!!
private final static long serialVersionUID = -1234567890123456L;...
}
-
Duh. That can be automatized: http://thedailywtf.com/Articles/Serializalicious.aspx
-
This is really weird. What horrible WTF is underlying this particular use of serialization? Is it just used as some kind of file format versioning? Or an overcautious warning because someone might have changed some underlying assumption?
-
At first I thought this might've been an attempt to prevent (de)serialization of a class that, for some reason, had to extend a Serializable superclass but could not actually be safely (de)serialized itself. But if so, it's a really crappy "solution". (I think the correct way to do that would be to implement the writeObject and/or readObject methods and make them throw a NotSerializableException.)
Since the comment suggests that they're doing automated source code mangling at compile time (which is probably TRWTF), I suppose some part of that mangling might also make the classes incompatible. In which case they would, technically, be using serialVersionUID exactly as intended.
-
It's not often that I see code which fails both at the conceptual and implementation level.
