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.
Let's say you define the following basic class with NB: public class MyException extends Exception { } Nothing else. NB is happy, shows no error, no warning, no fix options, no nothing. However, when you compile it, surprise surprise: Compiling 2 source files to /Foo/.build/classes/src /Bar/MyException.java:12: warning: [serial] serializable class to.berger.analab.data.MyException has no definition of serialVersionUID public class MyException extends Exception { 1 warning The JDK compiler rightly complains that serialVersionUID is not defined. Now what to do? you need to go search the web to find how to use that old commandlind tool serialver or what's not. NB is great, but I think it is a shame that with all the advanced features available for editing, the simple task of writing a correct serialVersionUID is not automated. Especially now that the JDK generates a warning for that. Because of the following 4 reasons: 1) This is a very very common case. 2) The fix is probably straightforward, because I remember that serialVersionUID was already implemented in some old version of NB 3) The workaround (using serialver command line tool) is a complete pain in the ass (who remember the syntax, arguments, location of that tool?) 4) Many people have complained about that already in the past. I think that enhancement deserve a P2 priority AT LEAST (if not P1). Please :) :) :)
Well, I agree that this would be nice. Cannot really say how common case it is. But it is certainly pretty complicated to do correctly (in production quality). This is because the only simple way to compute the sVUID is to actually load the class into a VM and ask ObjectStreamClass (I am not 100% sure offhand that this is the correct class to ask). But, the hints use extensible framework, so this can be added through an (external) module - any volunteer? I can give some hints on how to write it. BTW: you can enable the warning in Tools/Options/Java Code/Hints/Standard Javac Warnings.
Actually, I don't think you need to load the class in a VM. Looking at computeDefaultSUID on google: http://dmi.ensica.fr/doc/Java/j2sdk-1_4_2-doc/docs/j2h/java/io/ObjectStreamClass.java.html It seem that this method (computeDefaultSUID) could be replicated relatively easily: It's a question of getting the list of fields, methods, interfaces, sorting them in alphabetical order, and taking a SHA1 hash of that mix. I'm sure all the info needed is already available to NB (for things like refactoring and all) without loading the need to load the class in a VM. Thanks for the warning hint :) Cedric
Well, I said "simple way", and I do not think that replicating this algorithm qualifies as "simple" - one needs to ensure that the generated sVUID are compatible (ie. the same) in all cases - which may mean to do and write quite some tests and fixes. The needed information indeed is easily accessible from the parser. I welcome contributions on this one :-).
Guys, you really don't need to generate serialVersionUID using the algorithm outlined in the specification. You only need that to provide backwards compatibility for classes which been mistakenly published without it. In the case of new classes (which are far more often) why not generate a serialVersionUID of 0?
*** This issue has been marked as a duplicate of 85530 ***
Found a better issue to duplicate against
*** This issue has been marked as a duplicate of 70746 ***