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.
Summary: | Display warning when serializing instances of classes which do not declare serialVersionUID | ||
---|---|---|---|
Product: | platform | Reporter: | _ ttran <ttran> |
Component: | -- Other -- | Assignee: | _ ttran <ttran> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | eadams, jchalupa, jglick, jtulach, mkubec, pnejedly |
Priority: | P1 | ||
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | TASK | Exception Reporter: |
Description
_ ttran
2002-01-29 21:11:06 UTC
Also see issue 19483 for more thoughts. *** Issue 19483 has been marked as a duplicate of this issue. *** Runtime check!? That will slow down the serialization, should not the check be build-time? when you serialize instances you usually (at least in our context) you must subsequently do some I/O operations which are *much* slower than CPU. So I do not care that much if the performance degradation does not take 10 minutes. Of course we need to do some measurements to get the hard numbers. Not sure about the runtime check overhead, but it seems to me that the infrastructure implemented by Milan Kubec could be used at build-time. It is a kind of post-build checking task similar to the API signature tests. Implemented in CVS trunk (NB 3.4) (I've stolen a piece of code from Milan :-). The warning output is er___ interesting. Even some anonymous inner classes are serialized, which is of course double evil. The check is done in NbObjectOutputStream which I hope is used for all serialization needs in NB. Petr Nejedly, can you please check the performance impact? I believe there is virtually none, because we should not touch the hard disk during time sensitive periods anyway. The diff is http://openide.netbeans.org/source/browse/openide/src/org/openide/util/io/NbObjectOutputStream.java.diff?r1=1.14&r2=1.15 Jesse suggests to warn also about abstract instances: http://www.netbeans.org/servlets/ReadMsg?msgId=253190&listName=nbdev because if serializing class that has a superclass without SUID we can get into similar problems as well... Trung please check, but I think your patch already does this fine - AFAIK annotateClass is called with the superclass by the object stream anyway. Btw. after the issue 17164 has been implemented the serialVersionUID is not a stopper for loading old version of classes. Its check can be suppressed. That might indicated that the check implemented as part of this issue can be deleted. #17164 is useless for people who are switching between JDK 1.3 and JDK 1.4 (myself included). For this reason forgetting to declare svuid is still a showstopper. Quoted from http://java.sun.com/j2se/1.4/compatibility.html ---8<--- * If a serializable inner class contains explicit references to to its class object, then the computed value of the serial version UID for the class will be different in J2SE 1.3 and J2SE 1.4. The difference is due to the fact that the computation of the serial version UID is sensitive to modifications made in the javac compiler between J2SDK 1.3 and J2SDK 1.4. To avoid this problem affecting your applications, we recommend that you add an explicit serial version UID to your serializable classes. You can use the serialver tool to obtain the serial version UID of classes compiled with the J2SDK 1.3 javac compiler. ---8<--- end of quote --8<-- Trung you misunderstand. Issue 17164 is solution for this problem - nevertheless what the JDK documentation says. I've reread the description of this issue and the solution described
in issue 17164 and cannot see how the latter can makes the former
obsolete. Specifically I disagree with Yarda's statement
> That might indicated that the check implemented as part of this issue
> can be deleted.
x x verified This issues prints warning every shutdown due to java.util.TreeSet. Please exclude the TreeSet from the check. No! This warning *should* be there. See issue #21781. No, no. Issue 21781 is completely invalid and should be wontfix, the TreeSet should be removed from the check and a bug (more enhancement) for the JDK team should be fired ensure that they will either add the serialVersionUID to the TreeSet or keep the computed UID the same. Do we think they do not have backward serialization compatibility tests? IMO, no module should be serializing TreeSet directly and depending on its serialization format. Usage of TreeSet is an internal implementation detail. For the purpose of persistence, it should be translated into a simpler, JDK-independent form. Issue 21781 should be taken seriously. Jan, are you talking about the future vision or current state? If the later, then you should also say that no module should serialize HashMap, ArrayList, Vector and all those other classes that we do serialize. Your comment can be easily applied to any other utility class not just TreeSet. I think it is ok to have your opinion for the future vision, but it has to be understood that usage of TreeSet is not worse than usage of ArrayList, which nobody complained about yet. I'm talking about the vision we should have adopted and implemented long time ago. And yes, I think that using serialized instances of utility classes for the purposes long-term persistence is evil. This includes ArrayList, Vector, Hashtable, HashMap, String, (name your Java class). And it really doesn't matter whether the serialization format is native Java serialization or XML. The bad thing is that internal implementation details get exposed where they shouldn't be. I know my proposal sounds too radical, given the current implementation, but I really think we should be moving in that direction. Ok, I suggest to create another issue for vision things and dedicate this one just to what is written in its summary. Good point. See issue 27484. |