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.
Import of project from release 321, where txt editor was openned throws IOE saying that class serial UIDs are incompatible. Project and exceptions are attached.
Created attachment 4108 [details] exception stack trace
Created attachment 4109 [details] project dir
It is an incompatibility in the text module.
see also: http://www.netbeans.org/issues/show_bug.cgi?id=17618 we will preferably be compatible with 3.2.1 rather then 3.1 if we have to choose
I think it's too late because if we change it to be compatible with 3.2.1 it will not be compatible with 3.3. What do you think?
Too bad. I guess there is not too much chances to read 3.2.1 version - but that does not matter too much, it is just text editor window... We should concentrate on not reporting the exception if possible. The code will have to go to WindowSystem, because the exception is reported by it and not by project module, as far as I can see - I am thinking about catching the java.io.InvalidClassException and if the invalid class has been info and the bean info is saying info.getValue ("ignoreClassException") then we could ignore the exception completely and not report it to the user!? Wh't da'ya thinka bout th'a?
I agree. Thanks Yarda.
Another solution: WindowManager does not report the exception by itself, but just throws org.openide.util.io.SafeException (with good annotations) to the system. Project module can investigate it and realize that TxtEditorSupport is fine to fail!?
Teda FUJ. I agree with the solution to catch and not report this error, although it is ugly. Marek, please take care of the implementation. But Marek will need exact description of what he's supposed to do, Yarda and Mila please help Marek, we (winsys guys) don't know background of this at all. As this is *ugly* hack, I vote for placing it on one place (not spread across winsys and projects) and document into the code when this hack can be removed (4.0 probably).
Created attachment 4178 [details] Yarda's idea&proposed patch.
I'd like to ask QA to test the patch on [release33] build, and if successful, then approve it. Note about solution: It allows us to specify for deserializing class also other serialVersionUID's which are compatible with current class then the one computed or loaded thru the well-known field. Explanation it's not in [main-trunk] yet: As Yarda said, for [main-trunk] there is needed more general (long-term) solution allowing also others in nice, easy maintainable way to specify other compatible serialVersionUID's for some class name. Something like what is done for packages in Utilities.translate. For fixing of this issue, i.e. for 3.3.1 is enough just to hardcode the one class with one more serialVersionUID (see the patch). Thanks
I approve. This is an ugly hack and we must be sure to work on a more correct solution for the trunk. Can someone file a bug against 3.4.
[QA] Patch verified in 3.3.1rc1.
Approved by QA.
*** Issue 18457 has been marked as a duplicate of this issue. ***
Created new task to find more correct solution, see issue #19483.
After rethinking put the fix in [main-trunk]. Fix: openide/../util/io/NbInputStream.java [1.20] So the finding for generic solution doesn't get forgotten, is the new issue created (#19483) enough (see comment there). But up to the time, there should be this issue fixed as well in trunk.
peter, go integrate it into release33. [You already set the "Target Milestone" to 3.3.1. This should be done only after the fix is integrated into release33 branch. Until that time the milestone should be "3.4"]
Integrated into [release33], thanks. Fix: openide/../util/io/NbObjectInputStream.java [1.19.14.1] Sorry, for too early change of the target milestone.
Verified in the build # 200201180727.
Resolved for 3.4.x or earlier, no new info since then -> closing.