The serializable class does not declare a static final serialVersionUID

[Kowshik Nandagudi]

1 ) What does The serializable class PositionCollector does not declare a static final serialVersionUID field of type long mean ?

2) What actually happens behind the scene if i implement Serializable class?

3) What is the role of this id?

[Campbell Ritchie]

Kowshik Nandagudi wrote:1 ) What does The serializable class PositionCollector does not declare a static final serialVersionUID field of type long mean ?

It means you are using Eclipse; other IDEs tend to keep quiet about it

. . .

3) What is the role of this id?

It ensures that you are deserialising from a particular version of a class to the same version. Imagine you have a Car class

public class Car
{
   private int speed;
   private int direction;
   private final Make make;
   private final String registration;
   private final Color colour;
   private static final long SerialVersionUID = 37458346586L;
/* etc etc */
}

Now imagine you add a new field to the class, in newer versions of the application.

public class Car
{
   private int speed;
   private int direction;
   private final Make make;
   private final String registration;
   private final Color colour;
   private CD_Player player;
   private static final long SerialVersionUID = 98599739738L;
/* etc etc */
}

If you serialize an object of the first Car class, and deserialize it into the newer Car class, where will the CD_Player object be? What the SUID does here, is to tell the JVM that despite the similar name, they are different classes. I think in that case, an Exception willl be thrown, but I am not certain.
There are at least three things you can do with SUIDs

1: Leave it out. That tells the JVM that you are not worrying whether different versions of the class are the same.

2: Use the same SUID throughout (unzip the String class and look at its code). That tells the JVM to treat all versions of the class as if they were the same version.

3: Give different versions different SUIDs. That tells the JVM to treat them as different versions, not mutually serializable with one another.

There is a serialver tool which adds a SUID to a class.

[Vijitha Kumara]

Main purpose of this is to check for the compatibility between the class file available for the JVM and the serialized object stream. Read all about it here
Edit: Ah... I had to go out a bit since started to reply to this. Campbell has already replied

[Ryan Bishop]

So how do you resolve it? Just ignore it? This has been happening to me a lot and I keep doing "suppress warning." Below does it but I don't see what I can do. It's just the name of a class the problem asks for.

import javax.swing.*;
import java.awt.*;
import java.awt.event.*;


@SuppressWarnings("serial")
public class JNumberOne extends JApplet implements ActionListener  //get error here.
{
	JButton personsNumberOne = new JButton("Who's number one?");
	JLabel answerNumberOne = new JLabel("Your mom");
	
	Font font = new Font("suck it", Font.BOLD, 24);

	Container containerAnswer = getContentPane();

	public void init()
	{
		
		answerNumberOne.setFont(font);
		answerNumberOne.setVisible(false);
		containerAnswer.setLayout(new FlowLayout());
		containerAnswer.add(personsNumberOne);
		containerAnswer.add(answerNumberOne);
		
		
		personsNumberOne.addActionListener(this);
	}

	public void actionPerformed(ActionEvent ae)
	{

		answerNumberOne.setVisible(true);
		validate();
	}
	}

[Dave Tolls]

Ryan Bishop wrote:So how do you resolve it? Just ignore it? This has been happening to me a lot and I keep doing "suppress warning." Below does it but I don't see what I can do. It's just the name of a class the problem asks for.

You could do as the warning suggests and add a 'static final serialVersionUID field of type long' to the class.

[Campbell Ritchie]

You should not declare the serialVersionUID until you have finished writing the class. You should ignore the warning until you have completed the coding.
There is an explanation of SUIDs in the Serializable interface, quoted here.
You have several options for tge SUID:-

1: Leave it out. That means you are permitting instances of that class to be deserialised from any serialised object.

2: Copy the SUID from another class. That means you are declaring those two classes to be equivalent to each other as targets for deserialisation. The java.lang.String class does this, copying the SUID from earlier versions of String, so all versions of String can be serialised and deserialised to each other.

3: Guess a number. That means you can only serialise and deserialise to and from objects with the same SUID.

4: Get the serialver tool to create a number. It looks at all the types of field and calculates a sort of hash. You can't do that until you have finished coding, otherwise the SUID generated might be different.

The Eclipse option generate SUID simply calls the serialver tool in the background.

[Ryan Bishop]

Thanks.

[Campbell Ritchie]

Your welcome