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.
Issue 19342 describes one example of a problem we are facing over and over: Module writers do not have a discipline to annotate their classes with proper serial version UID. Yes, it is their mistake, but they blame us for not providing them a way to recover from that problem. As described in issue 19342 there is a way to recover from omition of serialVersionUID - but such hacks should not be present in openide, but should be "plugable" - providable by modules themselves. Similar concept as in issue 17164 could be used here: read META-INF/serial.txt from all modules. The files would contain name of the class and long as identification of class version that is ok to be loaded even our current UID is different.
Current code in main trunk that references class of editor module has to disappear soon!
I am not convinced this is desirable. If a module writer does forget to annotate a class with svuid and changes it once, he can use the serialver tool to recover. If he has already published one version of a module without svuid and is working on a new version and forgets to add it - then QA ought to be testing backward compat of settings before the new version of the module is released! And QA should catch the mistake at that time. Also there are tools available to scan sources for missing svuid (e.g. serialversion module) which module writers should use if they need to.
Ok, but from UI perspective user should not pay for programmer being stupid. I agree with your comment that QA should be able to find the problem before release, but I am affraid we will have to provide a solution for unexperienced programmers.
Anyway this is just yet another case of why one shouldn't use serialization. It's too error prone. If we do use some readable, and well documented format for settings then this kind of hack is not necessary. Because we are talking about the future, what about setting the goal for 3.4/4.0 to solve the settings issues in a good way. I don't want to implement just yet another hack to fix deficiency in our API/designs of the system. We'd lose. [changed type to TASK and increased prio to P1]
I would agree with Trung, let's decide on a non-serialization (XML?) persistence technique and begin using it. We've delayed such a decision for too long already, it is a huge source of bugs during every release and needless work for QA.
Changed back to bug. If you do not want to fix it, close it, but this is a report about serialVersionUID not any other kind of settings store. For such refer for example to issue 17924.
Yarda, I still maintain that this is not a bug. And I am going to change the issue type back to TASK again. I believe the settings concept/architecture/implementation in NetBeans has serious flaws. We need to fix the whole thing, just one small hack won't save us. I am still against implementing your proposal described in this issue. How do you want to document it for example? If the thing is not documented and guarranteed to work in the future, then for the module developers it doesn't exist. I don't have any problem to put this hack in the code in the last minutes to save the release (3.3.1). But for 3.4 I would say we should try to solve the deeper issues in a better way. Please leave this issue open for discussions.
added jchalupa, eadams, jglick to the CC list. They probably have something to say
My $0.02: I don't object to the proposal if someone else wants to do it, and it is not considered official or permanent - perhaps used as a hack for 3.4 but no later. I think the developer effort (until we have better settings storage) might be better spent running a complete svuid check before the 3.4 release, and I am not so concerned about pzavadsky's hack so long as it is temporary.
The use of serialization for long-term persistence has continually caused problems. It needs to be eliminated. That being said, there is a legitimate use of serialization in RMI. The problem of a missing serialVersionUID is one the IDE can, and should, check for. This is analagous to the synchronization feature where the IDE notices that an interface has been changed and offers to change classes that implement it. If a class implemented Serializable and does not have a serialVersionUID, then the IDE should catch this and offer to insert it. Now back to the primary issue -- the elimination of all serialization for long-term persistence in the IDE. I hope there is agreement that this is necessary. I would like to see some brainstorming regarding the proper replacement. The current architecture tries to persist objects (that's a big part of the problem) when I think the goal should be to persist data (much more flexible). In the simplest archictecture a module is given an OutputStream and asked to save its state and, likewise, given an InputStream and asked to restore its state. The IDE would define some conditions under which the IDE invokes these methods (startup, exit, install, uninstall) and, when appropriate, the module could choose to invoke them more often. The hard part in this area is maintaining backward compatibility while allowing for evolution. A versioning scheme is necessary. It should be left up the module, to remember how to read older file formats, convert data, ignore date, etc. Thoughts?
The reason why this is a bug is revision 1.22 of http://www.netbeans.org/source/browse/openide/src/org/openide/util/io/NbObjectInputStream.java Such ugly code should not be there. Before changing this to task please remove the ugly code from main trunk.
This issue is drawing a lot of high-level discussion, I suggest it be moved to dev@openide until there is something like consensus. Let's restrict this issue to the narrow concern of either leaving the current hack in NbObjectInputStream until 4.0 and agreeing not to add more to it in the future, or providing a provisional API enabling modules to add to the list of hacked svuid's. I have no particular preference; both are undesirable. The first is less work.
Yarda wrote > Such ugly code should not be there. Before changing this to task > please remove the ugly code from main trunk. Jardo, seriously how many bugs do you want to file against ugly code in core/openide? I maintain that this is not a bug and going to close it as WONTFIX. What you suggested is just yet another ugly piece of API in the platform. Who is willing to maintain such a code? I am not. It's perfectly possible to write an automatic test to check for serializable classes whose authors forgot to declare svuid. See Milan Kubec's post on the mailing list. We can even run a runtime check for svuid before serializing class instances to file and complain loudly if it's missing. One more reason why I don't want to instutionalize the hack (read benevolence) we did for text and image module. One does not create new API everyday for each set of "all three users" :-)
> It's perfectly possible to write an automatic test to check for > serializable classes whose authors forgot to declare svuid. See > Milan Kubec's post on the mailing list. We can even run a runtime > check for svuid before serializing class instances to file and > complain loudly if it's missing I filed a TASK issue 19915 to investigate/implement this runtime check. Closed this one as INVALID
Verified, build-time check would be better.
Resolved for 3.4.x or earlier, no new info since then -> closing.