Why do you need to overload the Serialversionuid property in some Java classes? Which means that you write a property inside the class.
eg
Private static final long serialversionuid = -1575386983723846021l; (General eclipse will automatically generate the data behind)
In Java, software compatibility is a big problem, in particular, when using object serialization, when an object has been serialized, but the object has been modified and redeployed, then in this case, using the old software to read the new file format is not difficult, but it is possible to lose some information.
Serialversionuid to solve these problems, the new serialversionuid must be defined in the following form: Static final long serialversionuid=-2805284943658356093l;. The L in which the number is appended indicates that it is a long value. This way to solve the problem of string lingo between different versions.
Outline:
━━━━━━━━
I. Overview
Second, Java serialization
Iii. introduction of the version number
Iv. concluding remarks
━━━━━━━━
I. Overview
After a program is officially released, adding some new functionality often means modifying the way that the user saves the data--and the format in which the program saves the file--usually by increasing the data saved to the file. In some cases, the file format must be thoroughly altered to match the new functionality of the implementation program. In this sense, the development/change of file format always echoes the functional improvement of the program.
However, in most cases, it is not feasible to lose the original data format. In the animal kingdom, the inability to adapt to the environment means death; software domains are similar, and whether the new software supports the original data format largely determines whether or not the user is upgraded.
No matter how much software has been added/improved, no matter how perfect the new file format is, if the new software cannot take advantage of the original file format, the user is generally less likely to endorse the new software. Solutions to this problem include:
Keep old code to read old files. This scenario typically requires additional code to convert old files to new formats (generally, the easiest way is to convert old file data into new internal objects, and then use existing objects written in the newer version of the file format). The advantage of this approach is that both the original code is retained and the new file format is compatible. However, this approach can sometimes lead to loss of some data, but better than losing all of the data.
Enable the new software to read/write old file format. This approach is much more intensive, because new versions of the program typically add features that are not previously available, and often lack some of the data required for new features in the old data format.
When the new software makes fundamental changes to the way it was originally performed, the loss of data is by no means a rare occurrence. If the new software is used in different ways to achieve the same effect, the original function may no longer have the necessary reservation. For example, if a program used to use swing as a user interface, and now change it to the Web (browser) user interface, many of the original user interface settings are no longer valid.
And if you have an email program, used to be a folder based index, now changed it to a word based indexing system, in the process of upgrading the index file format is likely to lose a lot of information; if the original index file saved many user configuration options and optimization measures, This data may not be available in the new indexing system.
There is no perfect solution to such problems, but we can take some steps to make the negative impact of the upgrade file format as small as possible. Given the simplicity of Java Serialization (serialization), which is increasingly becoming an important means of saving files, let's take a look at how the files saved through Java serialization remain compatible during the software version change process.
Second, Java serialization
Java serialization has a number of advantages:
Easy to use.
If an object is connected to another object, the serialization mechanism saves all the related objects.
If an object appears multiple times, the serialization mechanism is saved only once. This is extremely important, it not only reduces the file space, and even if the code is not very sophisticated, there is no need to worry about an infinite loop (an example of an insensitive case where you can save objects in a recursive way without effectively auditing which objects have been saved, and then you may end up in a never-ending loop).
Unfortunately, the file format defined by the Java serialization mechanism appears to be fragile, and as long as you change the definition of the Class A little, the original saved object may not be readable. For example, the following is a simple class definition:
Java code 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 field to this class definition, such as final int val = 7, and then read the original saved object, the following exception appears:
Java.io.InvalidClassException:
Save; Local class Incompatible:
Stream Classdesc Serialversionuid =-2805284943658356093,
Local class Serialversionuid = 3419534311899376629
The numeric string in the above example exception information represents the encoded values of the various attributes in the class definition:
The name of the class (Save).
The name of the domain.
The name of the method (Save).
The implemented interface (Serializable).
Altering any of these items (whether added or deleted) can cause a similar exception alert to be caused by changes in encoded values. This sequence of numbers is called the serialized version uniform identifier (serial versions universal identifier), referred to as the UID. The solution to this problem is to add a domain Serialversionuid to the class, forcing the class to still use the original UID. The new domain must be:
Static: The properties defined by this field work on the entire class, not on the specific object.
Final: Guarantees that the domain will not be modified while the code is running.
Long: It's a 64-bit value.
In other words, the new serialversionuid must be defined in this form: static final long serialversionuid=-2805284943658356093l;. The L in which the number is appended indicates that it is a long value.
Of course, the changed class will not necessarily be compatible with the original object. For example, if you change the definition of a field from string to int, the system does not know how to handle the value when performing a reverse-serialization operation, displaying an error message: 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 compatibility-related changes (http://java.sun.com/j2se/1.4.1/docs/
guide/serialization/spec/version.doc7.html) and incompatible changes (http://java.sun.com/j2se/1.4.1/docs/guide/
serialization/spec/version.doc8.html), which indicate what changes to the class might still read the original serialized data. The specifics are complicated, but it's easy to understand the main mechanisms:
In short, if you do save all the necessary data in a file, it is still possible to read the file, assuming, of course, that you must handle the UID of the serialization.
Iii. introduction of the version number
Many programs have inadvertently made the assumption that this file format is the last format I want to use, and no longer need to develop a new format, now to do is to deal with the various formats before this. This program tries to read a file with a higher format version, and the operation is halfway through the discovery of some unrecognized data and then suddenly crashes. If the file contains a large amount of metadata (the data that describes the file itself), it will be much easier to handle.
In Java, each field is explicitly labeled by its name, as long as the file changes are not very large (only added domain, has not been deleted or made significant changes in the domain), you can imagine that the old software to read the new file format is not difficult, although it is possible to lose some information, but you can find out the basic situation of the document.
The file format changes as the program functions. Ideally, the program should be both backwards compatible (the new version can be read in the old version, and may even allow updates), and be forward-compatible (older software can recognize and process the new version of the file format).
Typically, the version of a file cannot be seen from the surface. Most programs do not change the file name extension because of a different version of the file, and there is currently no uniform markup file version. Therefore, the version declaration on the file format can only be done within the file itself. If you are using a file format that does not contain a version statement, it is a good idea to add a version mark the next time you upgrade the file to an incompatible version, or find a way to add a version tag to the current file format without adversely affecting it.
Version information is generally declared at the beginning of a file because the program must first check the version of the file before processing it, and you do not have to read the rest of the file unless you have a version of the file defined.
By convention, the file version number contains two parts: the major version number and the minor version number. A particular version of a program should have the primary-minor version number that works best for it; changes in the major version mean a significant change in file format, and it is difficult to continue to use, and significant changes must be made to upgrade to a new version.
The primary and secondary version of a file can often be added to another item, called the "magic Number," which is to ensure that the file type that the program handles is not incorrect (because the file name extension may not be uniquely marked with a file type). For example, a Java class file always starts with the following byte content (hexadecimal): CA FE BA be. There are no unified registries for such numbers, but UNIX provides a list (but not complete) under/etc/magic. Magic numbers generally have four bytes, a large range of values, so generally do not have to worry about the occurrence of a conflict of value situations.
When writing and maintaining code that must read/write files, it is necessary to be aware of the forward/backward compatibility of the code. In the code that processes the file, the file version is first read, and the remainder of the file is passed to the appropriate processing method based on the version number, and the program should give a clear hint if the file version is too old to support.
Iv. concluding remarks
File format design is an extremely important topic, but there are still many details in this article that have not been covered. For example, for large files, we need random access instead of sequentially accessing the contents of the file from the back, so that you do not have to read the entire file in order to access the last few bytes of the file. Both XML and Java serialization support for such random access are not ideal, and the development of such file formats is more difficult to manage than plain files because they rely on byte-level access, and a slight change in file format may result in incompatibility.
The problem is compounded if you want the file to have acid characteristics--atomicity, consistency, isolation, and durability, i.e. atomicity, consistency, isolation, persistence. Acid is closely related to the concept of a transaction, enabling multiple users to access a file at the same time. For this type of file, consider using a small database system, such as Birdstep or Sleepycat. However, this has entered another area of file format management involving both the version of the database management software and the version of the data schema design.
Aside from these complex issues, in practice, many times we simply need a simple file to hold the data, and there will be no concurrent access to multiple users, and the entire file can be processed at once (or at least for sequential access). For these cases, it is best to design the file format to consider version problems, in the future operation, maintenance will bring a lot of convenience.
