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: | Handle serialVersionUIDs | ||
---|---|---|---|
Product: | java | Reporter: | cberger <cberger> |
Component: | Hints | Assignee: | Jan Lahoda <jlahoda> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | ||
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
cberger
2007-10-09 15:39:57 UTC
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 *** |