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.