Use of serialversionuid in java files

Why does serialversionuid need to be reloaded in some Java classes?
Attribute.

In Java, the compatibility of software is a big problem. Especially when the object is serialized, an object has been serialized, however, this object is modified and re-deployed. In this case, it is not difficult to use the old software to read the new file format, but some information may be lost.

Serialversionuid
To solve these problems, the added serialversionuid
It must be defined as follows: static final long serialversionuid
=-2805284943658356093l ;. The value of L after the number indicates that this is a long value. This method is used to solve the serial communication problem between different versions.

Outline:

When there are already too many other users

I. Overview

Ii. Java serialization

Iii. Introduced version number

Iv. Conclusion

When there are already too many other users

I. Overview

After a program is officially released, if you want to add some new functions, it usually means you must modify the user's way of saving data at the same time, that is, you must change the format of the saved files of the program-usually increase
The data stored in the file. In some cases, the file format must be thoroughly modified to implement new functions of the program. In this sense, the development/changes of file formats always echo the functional improvements of programs.

However, in most cases, it is impossible to lose the original data format. In the animal kingdom, being unable to adapt to the environment means death. The software field is similar. Whether the new software supports the original data format determines whether the user is upgraded.

No matter how many features the software has added/improved, no matter how perfect the new file format is, if the new software cannot use the original file format, users generally do not agree with the new software. Solutions to this problem include:

● Keep the old code to read the old file. To use this scheme, you usually need to write additional code to convert the old file into a new format (generally, the simplest way is to convert the data of the old file into a new one first.
Internal object, and then use the existing object to write to the new file format ). The advantage of this method is to keep the original code and make it compatible with the new file format. However, this method may sometimes lead to the loss
Data splitting is better than data loss.

● Enable the new software to read/write old file formats. This method requires a lot of work, because the new version of the program generally adds some features that are not available in the past, and the old data format usually lacks some data necessary for new features.

When the new version of the software made fundamental changes to the way the original task was executed, data loss was never a rare accident. If the new software version achieves the same effect as the original one
Functions may no longer be necessary to retain them. For example, if a program originally uses swing as a user interface and now changes it to a web (browser) user interface, many of the original user interface settings will no longer have
Effect.

Another example is that if a mail program uses a folder-based index, it is now changed to a word-based index system, many information may be lost during the process of upgrading the index file format. If the original index file stores many user configuration options and optimization measures, the data may not be available in the new index system.

There is no perfect solution to such problems, but we can take some measures to minimize the negative impact of File Format upgrade. Java serialization
Serialization is simple and easy to use, and is increasingly becoming an important means of saving files. In view of this, we can see that during the software version change process, through the Java string
How to maintain compatibility of Row-based files.

Ii. Java serialization

Java serialization has many advantages:

● Easy to use.

● If an object is connected to another object, the serialization mechanism will save all related objects.

● If an object appears multiple times, the serialization mechanism is saved only once. This is extremely important because it not only reduces the file space, but also does not have to worry about Infinite loops even if the code is not well written. (In an example of not sophisticated code, when each object is saved recursively, but it fails to effectively audit which objects have been saved, it may fall into a permanent endless loop ).

Unfortunately, the file format defined by the Java serialization mechanism seems very fragile. If you change the class definition a little, the originally saved object may not be readable. For example, the following is a simple class definition:

Public class save implements serializable

{

String name;

Public void save () throws ioexception

{

Fileoutputstream F = new fileoutputstream ("foo ");

Objectoutputstream OOS = new objectoutputstream (f );

Oos. writeobject (this );

Oos. Close ();

}

}

If you add a domain in the class definition, such as final int val = 7;, and then read the originally saved object, the following exception occurs:

Java. Io. invalidclassexception:

Save; local class incompatible:

Stream classdesc serialversionuid
=-1, 2805284943658356093,

Local class serialversionuid
= 3419534311899376629

In the preceding example, the numeric string in the exception information indicates the encoding values of various attributes in the class definition:

● Class Name (SAVE ).

● Name of the domain ).

● Method name (SAVE ).

● Implemented interfaces (serializable ).

Modifying any of the above items (whether added or deleted) will cause a change in the encoding value, resulting in a similar exception alert. This digital sequence is called the serial version universal identifier (UID. To solve this problem, add a domain serialversionuid in the class.
, Force the class to still use the original uid. The new domain must be:

● Static: attributes defined by this domain act on the entire class, rather than specific objects.

● Final: ensure that the domain is not modified during code running.

● Long: it is a 64-bit value.

That is, the added serialversionuid
It must be defined as follows: static final long serialversionuid
=-2805284943658356093l ;. The value of L after the number indicates that this is a long value.

Of course, the modified class is not necessarily compatible with the original object. For example, if you change the definition of a domain from string to int, the system does not know how to perform the inverse-serialization operation.
The error message: Java. Io. invalidclassexception: Save; incompatible types
Field name.

Java serialization specification (http://java.sun.com/j2se/1.4.1/docs/guide/

Serialization/spec/serialtoc.doc.html) provides compatible changes (http://java.sun.com/j2se/1.4.1/docs/)

Guide/serialization/spec/version.doc7.html) and incompatible modifications (http://java.sun.com/j2se/1.4.1/docs/guide/

Serialization/spec/version.doc8.html) List, which indicates which changes to the class may still read the original serialized data. The details are complex, but it is easy to understand the main mechanism:

In short, if all the necessary data is saved in the file, it is still possible to read the file, provided that the serial uid must be processed properly.

Iii. Introduced version number

Many programs have come up with the assumption that this file format is the last format I will use, and no new format will be needed in the future, what we need to do now is to handle the various cells before this
. This type of program will try to read a file with a higher version, only half of the operation will find some unidentifiable data, and then a sudden crash. If the file contains a large amount of metadata (the number of description files)
Processing is much easier.

In Java, each domain is explicitly indicated by its name. As long as the file is not changed significantly (only the domain is added, and the domain is not deleted or changed significantly), you can imagine that, reading New file formats with old software is not difficult. Although some information may be lost, you can understand the basic information of the file.

The file format changes with the change of program functions. Ideally, the program should be backward compatible (the new version can be read in the format of the old version, or even allow updates ), at the same time, it is forward compatible (older software can identify and process new file formats ).

Generally, the file version cannot be seen at a glance. Most programs do not change the file extension because of different file versions, and there is no uniform way to mark the file version. Therefore
The file version Declaration can only be performed within the file itself. If the file format you are using does not contain the version declaration, you are advised to add the version Mark immediately when you upgrade the file to an incompatible version next time, or
Users seek a way to add version tags to the current file format without any negative impact.

The version information is generally declared at the beginning of the file, because the program must first check the file version before processing the file, unless the file version is determined, otherwise it does not have to read the rest of the file.

By convention, the file version number contains two parts: the master version number and the next version number. A program of a specific version should have the primary-minor version number that is most suitable for processing. The major version number change means a major change in the file format and it is very difficult to continue using it, you must make major changes to upgrade to a new version.

Before the Primary and Secondary versions of a file, you can add another item, called "magic number". Its function is to ensure that the file type processed by the program is correct (because the file extension may not be unique ).
Specifies the file type ). For example, Java class files always start with the following column of bytes (hexadecimal): Ca Fe Ba
Be. There is no uniform registrar for such numbers, but Unix provides a list (but not complete) under/etc/magic ). Generally, magic numbers have four bytes and the value range is large,
Therefore, you do not need to worry about conflicting values.

When writing and maintaining code that requires reading/writing files, it is necessary to pay attention to the forward/backward compatibility of the Code. In the file processing code, read the file version first, and then pass the remaining content of the file to the appropriate processing method based on the version number. If the file version is too old, it is no longer supported, the program should give a clear prompt.

Iv. Conclusion

File Format design is an extremely important topic, but there are still many details not covered in this article. For example, for large files, we need random access, instead of reading the file content from the back to the back.
In this way, you do not have to read the entire file to access the last few bytes of the file. Whether XML or Java is serialized, this type of random access is not ideal, and the development of such file formats
Expansion and change are more difficult to manage than normal files, because they rely on Byte-level access, a slight change to the file format may lead to incompatibility.

If you want to make files acid-atomic, consistency, isolation, and durability, that is, atomicity, consistency,
Isolation and durability make the problem more complicated. Acid is closely related to the concept of transactions and allows multiple users to access a file at the same time. For such files, you can consider using a small database system, such
Birdstep or sleepycat. However, this has already entered another field of File Format management, involving both the database management software version and the data pattern design version.

Aside from these complex problems, in practice, we often only need simple files to store data without concurrent access from multiple users, the entire file can be processed at one time (or at least sequential access is suitable ). In these cases, it is best to consider the version issue when designing the file format, which will certainly bring a lot of convenience in future operation and maintenance.