-1

As per docs:

The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization.

If serialVersionUID is only meant to verify whether the sender and receiver of a serialized object have loaded classes for that object, then cant the class name itself be used by jvm for verification.

cooper
  • 603
  • 4
  • 10
  • 19

2 Answers2

4

You missed the latter part of the quote which says:

that are compatible with respect to serialization

You need an identifier which can be changed if you want to have multiple "versions" of the serialized class object. You can't do that with just passing in the class name.

To give an analogy, this is a bit like saying why we need to pass in the HTTP version (HTTP/1.1) since it is HTTP in the end. This is decide on the protocol "version" along with the protocol itself.

Sanjay T. Sharma
  • 22,857
  • 4
  • 59
  • 71
  • Doc states that the "serialVersionUID" must be **static**, **final**, and of type long ( i.e class level constant ). Then where the question of changing identifier arises.And at runtime, the loaded class name is anyway unique, then why cant jvm use the class name as an id, as long as the basic purpose is to verify that the sender and receiver of the serialized object have **loaded** **classes** for that object. Off course i am missing something. – cooper Sep 12 '14 at 16:26
  • @cooper: Think of an evolving class/schema. You can keep adding/removing fields from your class. To track these changes you can keep incrementing the version id. When serialized data is sent across, the receiver checks the "version" along with the class type; if the class type matches but the version doesn't, teh deserialization doesn't work out. This becomes critical when you are creating services like RMI wherein serialized class objects are exchanged between the client and the server and its important that both client and server are dealing with the same "logical" schema. – Sanjay T. Sharma Sep 12 '14 at 17:20
  • True sir.Nice Usecase.JVM considers all members of class,probably jvmVersion&OS also,while generating the UID.But DOCdoesn't state/recommend the use of UID for tracking the changes made to class structure.It states "_it is strongly recommended that all serializable classes explicitly declare UID values,since the default UID computation is highly sensitive to class details that may vary depending on compiler implementations_",seems like we explicitly to add patch.Theoretically tracking evolving class structure through UID is understandable, need to think on how far convenient/doable practically – cooper Sep 12 '14 at 19:53
  • @cooper: You are correct in questioning the usefulness of these ids. I have created RMI services in the past but given our client releases were perfectly synced up with server releases, there never was a need to mess around with version ids. I would imagine that if you are exposing an RMI service used by a large number of third-party clients and you have to absolutely ensure everyone is using the same class version, this concept might come in handy. So yes, not always useful but nifty feature if need be. – Sanjay T. Sharma Sep 12 '14 at 20:29
0

Well, to understand the concept of Serializable Class and its serialVersionUID, best place would be reading its complete java doc(java.io.Serializable), which explains with proper example.

Your question seems to be duplicate of this question. A proper and matured discussion has been done on this topic. Hope this helps.

Community
  • 1
  • 1
Sadique
  • 140
  • 8
  • Sir, looks like the discussion is about " **Why to use SerialVersionUID** ". If you don't mind, could you please copy the specific section from the matured discussion which precisely answers my question i.e **Why jvm generates serialVersionUID** ,instead of using class name itself for the verification purpose. – cooper Sep 12 '14 at 15:53