This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
We are always facing problem with different serialVersionUIDs while deserialization. Especially in the case when we want to be compatible with more than two releases at once. In the mentioned issue is proposed similar solution as for packages in Utilities.translate. See issue #19342 for more info.
The solution should be made some similar way it is done with packages. (see Utilities.translate implementation). There should be some place (txt file?), in some format allowing for concrete classes specify additional serialVersionUID's compatible with current classes.
There are probably two issues that need to be addressed and that seem very similar: 1. We currently support renaming of packages via Utilities.translate (...) - issue 17164 - but this should be enhanced to allow modules to specify what they want to rename and not hardcode it in openide 2. We seem to need to suppress serialVersionUID for some module classes that forget to add it - issue 19538 - again this should not be hardcoded in openide
Trung please find somebody who will solve the issue. Jesse, Evan please express your opinion about importance of fixing the bug. Here is Jesse's original opinion http://openide.netbeans.org/servlets/ReadMsg?msgId=237519&listName=cvs
To begin with I agree with Jesse comments -- we should not break compatibility of classes. If we have this discipline then there is no need solve this problem. Fundamentally, I don't like serialization for long-term persistence because of these and other problems. I hope that we slowly removing all instances of long-term serialization from the product. The most important thing to me is that we allow ourselves to be backward compatible with more than one release. Limiting ourselves to a single b/w compatible release is unacceptable. We can accomplish this be not breaking the compatibilty of classes or by providing these sort of "migration" facilities. I prefer the first technique. I'm curious about the details of 19342. What should have been done differently to ensure compatibility with older releases? How do we teach all the developers the tricks necessary to keep classes compatible?
[added jchalupa to the CC list, I know he does care a lot about setttings] > I'm curious about the details of 19342. What should have been done > differently to ensure compatibility with older releases? not using serialization. The trouble with serialization is that it's very hard to verify its compatibility. And we should assume that module developers are doing mistakes from time to time (we core developers don't :-). When the mistake already happened and committed into user data, we should try to help the module developers to recover from that if possible. I think this is what we should go after. > How do we teach all the developers the tricks necessary to keep > classes compatible? we can't, so don't do it. Settings compatibility means data compatibility. We can do better only when we have clearly defined format for each settings, whatever the format is I don't care. But it's must be documented as precise as possible. (Simple DTD doesn't cut it), for each module. The format must be taken as seriously as the API. Actually it's even more important than API, it's user's data. Just some thoughts
Marked this task as duplicate of issue 19915. In the long term we should completely avoid serialization and solve the settings related problem through a new design. This is a big task which requires more thoughts and discusions. *** This issue has been marked as a duplicate of 19915 ***
Problems with serialization solved. Future format of storage is covered by issue 17924