Comment On Serializalicious

I mean, this may be the best wtf ever.

Isn't that a cow-worker joke ? I did that kind of stuff, from time to time...

nextLong() ???

That hurts in sooo many ways!

785878927th one!

See, that's what happens when you inappropriately randomize longs.

Man, its been a non-stop WTF good post frenzy. Nice work Alex Papalodimilouishidious.

The REAL WTF is ... hm.. No, this is simply the best WTF - ever.

CAPTCHA: darwin - he would have cried if the coder had a child.

This isn't a wtf. The person is clearly implementing this strategy so that noone should be able to (unless really (un)lucky) to load an old instance of the class because the class is under development and as such is changing. Any attempts to load an old class would ofcourse fail.

So therefore it's important to ehh.. no.. wait.. It actually IS a wtf.

captcha: Sanitarium (I would need one)

Words fail. To quote Black Mage: I'd cry, but there aren't enough tears.

Me, I like Cocoa Puffs.

Of course, that might have been just a jesting effort to shut the stupid compiler up and keep it from complaining about a missing serialVersionUID in a class extended from one which implements the Serializable interface.

You'll find

    private static final long serialVersionUID = 42L; // To shut up compiler

in a lot of my classes which are never going to be serialized.

BlueEagle:

This isn't a wtf.
[...]
So therefore it's important to ehh.. no.. wait.. It actually IS a wtf.

Thanks for clarifying. I almost cried after your first sentence... ;-)

This is hell of a WTF. I couldn't decide whether to laugh, howl or choke after reading the article.
Great emotions on thedailyw...err worsethanfailure.com

"A pretty handy feature I might say. Without it, the API would need to rely on the compiled assembly’s version number"

Um, "compiled assembly"? We're talking about Java, not .NET...

In fact, the algorithm for working out the serial ID is part of the spec, but from what I remember it doesn't cover anonymous classes, leading to different compilers generating different serial IDs for the same class. Allowing the developer to specify it is a double-edged sword though: it allows consistency, but also leads to problems if they *don't* change it when they should...

Jon

Seriously serial seals migh get away with that, or would they...

That's a great wtf!

A pretty handy feature I might say. Without it, the API would need to rely on the compiled assembly’s version number (which might change on each compile) even if the class definition remains the same. But with a serialVersionUID, developers can be in control of whether or not two versions of a class definition are the same.

Yeah... sure be nice if .NET would do that.

The .NET assembly loading code is the biggest WTF I've ever seen in my life.

I know .Net, not Java so much, but in .Net the value here would be different on every run of any app that used this class. That what's gonna happen?

I thought I'd seen it all...

Steve:

You'll find

    private static final long serialVersionUID = 42L; // To shut up compiler

in a lot of my classes which are never going to be serialized.

Usually the compiler doesn't complain, but IDEs certainly do. I believe I've used that exact same comment before (although I'm usually slightly less creative with the arbitrary numbers I assign).

My daughter has the nickname of "Random" because of her non sequitors. I had pancakes for breakfast. The Cubs are in first place. So for Christmas I bought her a t-shirt that says, "I'm not random, I'm S4#zrq t8nm!"

Well, this code would allow objects to be serialized to and from the same ClassLoader (temp files?), but not between different JVMs or ClassLoaders, so maybe, just maybe, there's a smidgen of logic in there... Probably not that many projects are really concerned about rogue programmers surreptitiously serializing objects around, though...

LOL.

This isn't that WTF-y. Since static final is only instantiated once per VM this means the object can be serialized and read back in by the same VM. Shut down the VM and it won't reload the object, which might be what you want.

just great. reading wtf for a while now, been laughing at some over time but this is the best (worst?) of them all

we had a hilarious team meeting thinking about various other ways to determine serialVersionUIDs (reading unique ID columns from a DB, System.currentTimeMillis()...)

What's wrong with that?

All that happens is that when the application gets shut down and restarted, the class gets a (probably) different serialVersionUID and the instances that had been serialised before can no longer be deserialised. Am I wrong?

Basically, the persistent objects are valid only within one run of the application. Maybe that was just the design goal.

The even funnier thing would be if he always initialized that random util with the same seed and expected the numbers to be consistent...

But hey what are version numbers if not completely random numbers?

BlueEagle:

This isn't a wtf. The person is clearly implementing this strategy so that noone should be able to (unless really (un)lucky) to load an old instance of the class because the class is under development and as such is changing. Any attempts to load an old class would ofcourse fail.

So therefore it's important to ehh.. no.. wait.. It actually IS a wtf.

captcha: Sanitarium (I would need one)

From an objective standpoint, why even make it to where your loads will fail. Its serialization. The point is to save the object so you can load it later. If you don't want to load it later, don't serialize it in the first place !

n9ds:

My daughter has the nickname of "Random" because of her non sequitors. I had pancakes for breakfast. The Cubs are in first place. So for Christmas I bought her a t-shirt that says, "I'm not random, I'm S4#zrq t8nm!"

I would have bought her a t-shirt that says "I had pancakes for breakfast. Therefore I'm not random."

Newbie: So, what value should I set serialVersionUID to?
Local Guru: It doesn't matter, just pick a random value...
Newbie: Oh, okay...

Perhaps he wanted the class to be unserializable, although there might be a small chance it works.

Jerry:

Newbie: So, what value should I set serialVersionUID to?
Local Guru: It doesn't matter, just pick a random value...
Newbie: Oh, okay...

I vote yes.

It's a shame that serialization is rather limited in use. It's a nice feature for prototyping, but if you want to save data in a real application that will have application updates that might change class files, then you need to implement something a bit more meaty that will not fail to load your data after such an update.

As such, you're often better off getting this right from the beginning anyway, and never using the built-in Java serialization - or creating your own serialization implementation that is a bit more clever when loading in serialized data than the default.

It depends on how much control you want to have ultimately.

An apprentice:

All that happens is that when the application gets shut down and restarted, the class gets a (probably) different serialVersionUID and the instances that had been serialised before can no longer be deserialised. Am I wrong?

Basically, the persistent objects are valid only within one run of the application. Maybe that was just the design goal.

The key point is this: "Serialization allows instances of classes (i.e. objects) created at runtime to be saved and then later restored at a different runtime."

As I understand it from the article and the document linked to it, the Serialization happens automatically at startup and shutdown. Not only does this fail to actually utilize serialization as intended, it would result in exceptions every time the program ran for every object implementing Serialization.

Now I haven't programmed Java since college, but the documentation implies that you cannot serialize classes at will. It states, "The serialization interface has no methods or fields and serves only to identify the semantics of being serializable."

An apprentice:

What's wrong with that?

All that happens is that when the application gets shut down and restarted, the class gets a (probably) different serialVersionUID and the instances that had been serialised before can no longer be deserialised. Am I wrong?

Basically, the persistent objects are valid only within one run of the application. Maybe that was just the design goal.

Could be true, although it would have made more sense to just clean-up the previously serialized objects on shutdown/start-up. Serialization in Java is a nice feature that turns out to be inconvenient and often not worth the hassle, plus it tempts devs to do dumb stuff like serialize java objects to databases. I have seen this in the wild.

The beans package provides XML persistence which is generally more flexible and ends-up with human readable/editable files.

Now I haven't programmed Java since college, but the documentation implies that you cannot serialize classes at will. It states, "The serialization interface has no methods or fields and serves only to identify the semantics of being serializable."

You understand wrong. No objects are automatically (de)serialized on start-up or shutdown, you have to do it yourself with ObjectInputStreams / ObjectOutputStreams.

Jerry:

Newbie: So, what value should I set serialVersionUID to?
Local Guru: It doesn't matter, just pick a random value...
Newbie: Oh, okay...

I'll bet that's exactly what happened.

ElQuberto:

This isn't that WTF-y. Since static final is only instantiated once per VM this means the object can be serialized and read back in by the same VM. Shut down the VM and it won't reload the object, which might be what you want.

You mean it is a serial[ization] killer?

The full story is that I was brought on to an existing project to do a few weeks of work and finish up the loose ends.

I had been told tales of The Architect. Note that Steve is a co-suffererrer of The Architect, and absolutely not The Architect himself. The Architect was, of course, long gone.

The Architect was, if memory serves, a chemical engineer who had done a small amount of ASP development. That made The Architect perfect to take on this rather large J2EE web application.

I'm sure at some point, The Architect read something inside a book about how assigning a serialVersionId was a good idea. And that the values the JVM would assign looked random. And that you could assign any value you wanted. He just missed the "any FIXED value" part. Random.nextLong() it is!

Discoverring this line of code caused a mixture of hysterical giggles and bone numbing dread.

Of course, this was a DTO transferred between layers. Of course that code not only wasn't tested but wasn't needed, and was never used. But it was still there.

The project in question is a near perfect WTF. A .NET consulting shop hits a Goverment Organization that insists on a Java implementation (despite not having any Java developers, just COBOL). A clueless sales VP signs a fixed-bid contract promising it in six months. It's been about three years so far. In fact, I wouldn't be surprised if Steve posted a whole series of WTFs from this one amazing code base.

My month helping out would have been incredibly agonizing ... had I not met Steve and Ben, who are still suffering this stuff out.

-- Howard Lewis Ship

@SuppressWarnings("serial") ... or something like that. Eclipse puts it in for me. Or configure your IDE to turn that warning off.

Basically, the persistent objects are valid only within one run of the application. Maybe that was just the design goal.

I don't really agree. The point of serialization is to save an object for use in another JVM. (Program restart, passing objects from client to server, etc.) If the object was only valid for a single JVM, just don't unload the object from the JVM.

Now, if only I could imagine when I would need objects to be persistent except they shouldn't be...

I did a google search to see how many google can find.

http://www.google.com/codesearch?as_q=serialVersionUID.*compiler&btnG=Search+Code&hl=en&as_lang=java&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=

Just to help here, serialization:-

a.) doesn't happen at startup/shutdown, it happens when you read and write from the stream

b.) that stream is often something really useful like a Java Message Service or RMI endpoint, so what you are doing is sending/receiving objects to/from another running process. Hence you *want* two JVM's to understand each others objects (but only if the supporting class code is truly compatible)

This is why other commentators have questioned why you'd only serialize objects within a single JVM when you could much more quickly pass the object itself directly.

c.) yes you can serialize at will. Serialiable is a marker interface that just tells the compiler that you want to be able to serialize this thing. The fact that it has no methods is irrelevent. Think of it like a keyword like public/private/protected or perhaps volatile. As far as running bytecode is concerned there is not much meaning but the compiler does or expects certain things when it is encountered.

MurfWTF:

Serialization in Java is a nice feature that turns out to be inconvenient and often not worth the hassle, plus it tempts devs to do dumb stuff like serialize java objects to databases. I have seen this in the wild.

I really don't see what could possibly considered inconvenient about Java serialization. And unlike what nearly all comments here seem to be assuming, its main use is NOT persistence, but network communication.

Wow. Just... wow.

Sincerely,

Gene Wirchenko

anjan bacchu:

I did a google search to see how many google can find.

http://www.google.com/codesearch?as_q=serialVersionUID.*compiler&btnG=Search+Code&hl=en&as_lang=java&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=

That's nothing. Try this Codesearch on for size!

http://www.google.com/codesearch?hl=en&lr=&q=serialVersionUID.*random+lang%3Ajava

Incredibly, Howard's find isn't a one-off!

ShelteredCoder:

Basically, the persistent objects are valid only within one run of the application. Maybe that was just the design goal.

I don't really agree. The point of serialization is to save an object for use in another JVM. (Program restart, passing objects from client to server, etc.) If the object was only valid for a single JVM, just don't unload the object from the JVM.

C provides a serialization of pointers (printf/scanf %p) with the same characteristics (only valid within one run of the application).

Here's some JavaScript code which can generate you a serial version UID:

var m=Math;r=m.random;(r()<0.5?'-':'')+m.round(m.pow(10,17)*r())+'L'

More info available here

htg:

It's a shame that serialization is rather limited in use. It's a nice feature for prototyping, but if you want to save data in a real application that will have application updates that might change class files, then you need to implement something a bit more meaty that will not fail to load your data after such an update.

As it happens, the serialVersionUID is exactly what enables a serialized instance to be deserialized after a change to the class file unless the change is something very drastic (like changing the class's inheritance hierarchy, changing a field's type or, of course, removing the Serializable interface). If your data's structure changes that much, you're in for some work with any persistence mechanism.

As such, you're often better off getting this right from the beginning anyway, and never using the built-in Java serialization - or creating your own serialization implementation that is a bit more clever when loading in serialized data than the default.

It depends on how much control you want to have ultimately.

If all you want is to store the data and load it again, there really isn't any good reason not to use the default serialization. If you need the stored data to confirm to a specific format, then you can do that too, via the Externalizable interface, and still use many of the serialization mechanisms (like ObjectOutput/InputStream).

Steve:

...
You'll find

private static final long serialVersionUID = 42L; // To shut up compiler

in a lot of my classes which are never going to be serialized.

Why are you making classes "implement Serializable" if they will never be Serialized...WTF.

ElQuberto:

This isn't that WTF-y. Since static final is only instantiated once per VM this means the object can be serialized and read back in by the same VM. Shut down the VM and it won't reload the object, which might be what you want.

This doesn't account for the fact the class itself could be garbage collected and then you couldn't even deserialize the object from within the same VM. It also doesn't allow a different ClassLoader's version of the class to be loaded within the same VM. Static isn't once per VM, it's once per class load.

ShelteredCoder:

Basically, the persistent objects are valid only within one run of the application. Maybe that was just the design goal.

I don't really agree. The point of serialization is to save an object for use in another JVM. (Program restart, passing objects from client to server, etc.) If the object was only valid for a single JVM, just don't unload the object from the JVM.

Not necessarily...or, maybe you never needed to clone an object for use with the clipboard/dragdrop, etc.?

Use -1L and a serialVersionUID will be created for you that will differ every time you change the interface. In other words, it does what it's supposed to do. Why Serializable couldn't do this by default if the property didn't exist ... well, there's plenty of WTF's in the Java standard library.

BG:

Steve:

...
You'll find

private static final long serialVersionUID = 42L; // To shut up compiler

in a lot of my classes which are never going to be serialized.

Why are you making classes "implement Serializable" if they will never be Serialized...WTF.

Because they extend objects which are Serializable, such as HttpServlet.

ShelteredCoder:

Basically, the persistent objects are valid only within one run of the application. Maybe that was just the design goal.

I don't really agree. The point of serialization is to save an object for use in another JVM. (Program restart, passing objects from client to server, etc.) If the object was only valid for a single JVM, just don't unload the object from the JVM.

Maybe you want to put your program into a "sleep mode", and offload as much data as possible to a temp file until it wakes up to reduce memory usage?