Why is serialversionuid in the Java file?

[Transferred from: http://tbase.itpub.net/post/4931/4226920.the Java file contains the serialversionuid.

Why do I need to overload the serialversionuid attribute in some Java classes.

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 new serialversionuid must be defined in the following form: 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 features, it usually means you must modify the way users save data at the same time, that is, you must change the format of the file to be saved by the program. Generally, the data stored in the file is added. 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 internal object first, and then use the existing objects written 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 of some data, but it is always better than the loss of all data.

● 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 version of software achieves the same effect as the original method, the original functions may no longer be necessary. 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 work.

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 is easy to use and has become an important means of saving files. In view of this, let's look at the software version change process, how to maintain compatibility of files stored in Java serialization.

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 =-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, and 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 to say, the new serialversionuid must be defined in the following form: 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 handle this value when performing the inverse-serialization operation, and the error message is displayed: Java. io. invalidclassexception: Save; incompatible types for 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 formats 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 a file contains a large amount of metadata (describing the data of the file itself), it is much easier to process it.

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 version Declaration of the file format 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, you can also 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 types of files processed by the program are not correct (because the file extension may not uniquely indicate 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 ). Magic numbers generally have four bytes and have a large value range. Therefore, you do not have 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 sequential access to read the file content from the back to the back, so that we do not have to read the entire file to access the last few bytes of the file. Both XML and Java serialize support for such random access is not ideal, and the development and changes of such file formats are more difficult to manage than normal files because they rely on Byte-level access, A slight modification to the file format may result in incompatibility.

If you want to make files have ACID properties-atomicity, consistency, isolation, and durability, that is, atomicity, consistency, isolation, and durability, the problem becomes more complex. 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 as 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.