Serialization

[Migrated From Jforum.net]

Hi,

I don't know for the other but my IDE (Eclipse) warn about all the sources because classes are serializable (or have to be serialized) and do not implements the final static long serialVersionUID member.

I tested on my personal project to follow what J2EE says about Serialization and I was surprise by the result.

If you follow the rule to create this member, first you have to implement java.io.Serializable for all child object implemented in these classes. And for all of them you have to create the member serialVersionUID (because you implements java.io.Serializable). My IDE proposes to generate it for me automatically and this is very useful to correct it fast (quick fix on warning messages).

The result is that when someone is in the website, with objects in session, especially for a forum such as JForum, if for any reason the server restart, if the user stays on the same window - same session so, the user will not loose all the info (connected info, post, etc...). The server restored them for him automatically (principe of Serialization is to store phisically status of object).

So I suggest to implement this for the next version. Personnaly, I already implement it for JForum in 30minutes and it's powerfull
[originally posted on jforum.net by Blackwings]

[Migrated From Jforum.net]

hehe.. I disabled this eclipse feature here, because there were too much complains

Setting serial version uid to a fixed value forever is much like a hack, because you were supposed to handle different versions. But as it is hard to get used to, almost everyone set the value to 1.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

It's why I asked Eclipse to generate an ID for me ;)

In the beginning I was fed up of these warnings and errors in the logs, and I decided to understand what was this feature :roll:

I thought it is very usefull but you can live without that

Of course, if you put 1l as ID, it'll be very simple to "hack" the system... but finally, what a hacker can do with session object :?:

So, why not? ;)

[originally posted on jforum.net by Blackwings]

[Migrated From Jforum.net]

Well,

The question is that you don't need a serial version uid for your class to be serializable, if you don't generate one the JVM will create one for you, the only problem is that if you recompile the class and change something, even if you don't break compatibility, the JVM will complain because the newly generated serial version uid won't match the old one.

That's why it is recommended in many cases to specify one, which you need to modify when you make incompatible changes to a class.

The thing about restarting the server and still having the session has to do just with the objects inside the session being serializable. It does not depend on the serial version uid, unless the restart implies a new version of the classes inside the session have been loaded. That is a common servlet container feature, so you just need to make sure all objects in the sessions are serializable and configure the container appropriately.

Lastly, the serial version uid has nothing to do with "hacking", I think Rafael meant that many people define a static value and never change it, even when making incompatible changes, just to get rid of the eclipse warnings. That is an ugly solution and bad programming practice -> "hack" .
[originally posted on jforum.net by GreenEyed]