Bug 70746 - Auto-generate serialVersionUID data member and value
Auto-generate serialVersionUID data member and value
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Hints
6.x
All All
: P2 with 10 votes (vote)
: 6.x
Assigned To: Jan Lahoda
issues@java
: NETFIX
: 57293 58917 85530 95708 100366 117990 118255 (view as bug list)
Depends on: 193699
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-22 18:11 UTC by Craig Conover
Modified: 2013-07-14 15:33 UTC (History)
11 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Proposed patch against main-golden with tests. Inspiration from Michal Hlavac's plugin. (18.11 KB, text/plain)
2009-05-05 22:12 UTC, fommil
Details
Path to handle anonymous classses that implements Serializable interface (3.90 KB, text/plain)
2009-08-25 08:43 UTC, hlavki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Craig Conover 2005-12-22 18:11:43 UTC
It would be very convenient, and should be very easy to create this feature, to
be able to select one or more java source files, and click a Tools menu action
to insert a serialVersionUID data member with the default value based on the
serialver command.
Comment 1 Jan Becicka 2005-12-22 18:49:38 UTC
See http://serialversion.netbeans.org/
Comment 2 abs 2007-02-06 13:56:05 UTC
I can't access http://serialversion.netbeans.org/. Why?
Comment 3 tomzi 2007-03-13 12:36:25 UTC
Please provide:
* Add default serialVersionUID -> 1L
* Add generated serialVersionUID -> autogenerated
* Suppress warning by adding @SuppressWarnings("serial")

If a serialVersionUID already exists and the source has been changed it could
also be made possible to regenerate the UID.
Comment 4 Jan Pokorsky 2007-04-10 12:31:21 UTC
*** Issue 95708 has been marked as a duplicate of this issue. ***
Comment 5 Jan Pokorsky 2007-04-10 12:32:52 UTC
*** Issue 58917 has been marked as a duplicate of this issue. ***
Comment 6 Jan Pokorsky 2007-04-10 12:34:04 UTC
*** Issue 100366 has been marked as a duplicate of this issue. ***
Comment 7 athompson 2007-04-10 14:32:57 UTC
you could also place the serial ID in the template for a class, as mentioned in
#100366...
Comment 8 athompson 2007-05-29 19:13:04 UTC
the option probably better belongs in the 'Generate Code...' action.
Comment 9 tomzi 2007-08-01 13:42:51 UTC
What about having some sort of action that automatically regenerates serialVersionUID when the signature of the class
file changed?
Comment 10 _ gtzabari 2008-01-08 21:18:27 UTC
*** Issue 77345 has been marked as a duplicate of this issue. ***
Comment 11 _ gtzabari 2008-01-08 21:19:48 UTC
*** Issue 118255 has been marked as a duplicate of this issue. ***
Comment 12 _ gtzabari 2008-01-08 21:21:01 UTC
Increasing priority because of duplicate issues.

Please note that this issue is also related to #85530
Comment 13 _ gtzabari 2008-01-08 21:23:11 UTC
Currently the editor hints warn about a missing serialVersionUID but provide no quick-fix action. I am expecting a
quick-fix to generate serialVersionUID with a value of 0 or 1.
Comment 14 _ gtzabari 2008-01-08 21:24:05 UTC
*** Issue 117990 has been marked as a duplicate of this issue. ***
Comment 15 Andrei Badea 2008-01-15 14:37:49 UTC
*** Issue 85530 has been marked as a duplicate of this issue. ***
Comment 16 fommil 2008-01-28 21:46:06 UTC
7 dupes now... is anybody working on adding this to 6.1? It should be really trivial to add a code fix.
Comment 17 marco_bresciani 2008-01-28 22:24:15 UTC
cannot access http://serialversion.netbeans.org/ as well... no plugin available for this functionality?
Comment 18 fommil 2008-03-20 21:57:21 UTC
There is a lot of activity on this bug report... has it been assigned to anyone? Is anybody working (or even thinking about working) on it?

Almost everybody I know uses it and would miss it dearly if they came over to NetBeans. It's a real pain in the butt to have to create these fields manually.
Comment 19 Karthikeyan Rajeswaran 2008-04-09 00:26:41 UTC
*** Issue 57293 has been marked as a duplicate of this issue. ***
Comment 20 Karthikeyan Rajeswaran 2008-04-09 00:37:58 UTC
A plugin is available for this for version 6.0 at the plugin portal:
http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=6887
(According to the notes on the page, the plugin doesn't work for 6.1).
Comment 21 fommil 2008-04-09 00:50:25 UTC
I've never been able to find or install the plugin, but I believe this should be a part of the base hints and a plugin for something so small just seems weird.

It's not like Serializable is an obscure part of Java... it's one of the core interfaces! This hint would take away a lot of the boilerplate burden of making 
something Serializable.

Just look at the number of dupes in this bug report to see how much people want this very simple functionality. Even a default value of 1L would be enough to 
make me consider this bug solved! (In the meantime, I'm using a macro... but I forget it exists most of the time).
Comment 22 Jesse Glick 2008-05-22 16:32:10 UTC
The IDE could certainly have a hint to insert 1L, appropriate for new code.

The serialver command is only useful if you have made a public release of your software and later remember that you
forgot SVUID. The IDE could perhaps support this scenario also via an alternate hint which would open a file chooser.
You would need to select the JAR (or .class file) containing the released compiled class; the SVUID corresponding to
that release would be added to your current sources. That is probably the best the IDE can do since it does not know
about your releases. (In the case of Maven projects, in principle the IDE could identify the most recent non-SNAPSHOT
version of the module which can be found in your repository, and get the SVUID from that.)
Comment 23 twolf2919 2008-05-22 18:20:26 UTC
Yes, serialver is useful when you have an existing release where that was forgotten.  You'd be surprised how often that
happens, though.  Some developers don't know; others just forget.  The IDE doesn't provide a hint - maybe if it did, it
would help, but it wouldn't eliminate these occurrences.

As to how to integrate things into the IDE: a hint to add a line with '1L' is fine for new code.  A hint to add a SVUID
with the value as produced by serialver would be very helpful for existing java files.  I'm guessing the IDE could
invoke the serialver algorithm on the .class file in the build directory.  Wouldn't have to ask the user to point to a
specific instance that way (anything fancier, they could still run serialver manually).
Comment 24 Jesse Glick 2008-05-22 21:24:50 UTC
Running serialver on build/classes/ is unlikely to be what you want; would only work if you had made no structural
modifications to the class since its release. Better IMO to explicitly ask the user to point to the released code, so
they need to make a conscious decision which binary version to keep compatibility with.
Comment 25 hlavki 2008-05-28 19:15:48 UTC
I updated plugin for serialVersionUID. Version 1.3 works with netbeans 6.1. It didn't work because of functional 
changes in Javac Wrapper Library. Now it works only in 6.1 and generates default (1L) and calculated value from source 
code. It's not fully compatible with javac generator. It's compatible only for simple classes. So I will investigate 
to find reason.
This plugin doesn't work with latest nightly build because of code refactoring.
org.netbeans.modules.java.editor.codegen.CodeGenerator was moved to org.netbeans.spi.editor.codegen.CodeGenerator.

Download at http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=6887
Comment 26 fommil 2008-07-11 00:22:36 UTC
I've used the plugin, but the functionality feels hidden in the "insert code" menu... it really needs to be one of the hints when the IDE detects that 
serialVersionUID is not defined.

The lack of support for a hint on this really trivial matter is driving me bonkers... as a workaround I've created a macro that inserts the default 1L value if I 
type 'serial' and then my macro expander key (tab).
Comment 27 hlavki 2008-07-11 07:07:48 UTC
I don't understand because plugin use hints API and detects when serialVersionUID is needed. See this screenshot
http://plugins.netbeans.org/nbpluginportal/files/images/1211891934419_svuid.png
Comment 28 fommil 2008-07-11 09:46:37 UTC
Odd... is this the same plugin that can be obtained through the Tools->Plugins dialog?

Given the screenshot, I'd like to strongly urge the NetBeans team to make this a core feature of the Java Hints package!
Comment 29 athompson 2008-07-11 17:30:07 UTC
+1 to last comment
Comment 30 hlavki 2008-07-11 17:42:04 UTC
Yes, it is the same plug-in that can be obtained through the Tools->Plugins dialog.
Ensure if checkbox in options dialog (Java Code -> Hints -> APIs -> SerialVesionUID!) is checked...
Comment 31 fommil 2009-04-15 20:53:16 UTC
I understand this has been implemented already, there are 14 votes and I gave up counting the number of dupe reports.

What is the current state of this hint @hlavki, @msauer?
Comment 32 hlavki 2009-04-20 09:01:26 UTC
Algorithm is mostly written. Hint is provided as third party plug-in via plug-in portal at this moment. There is no
problem if you want to integrate it into netbeans sources. But I don't know process how to integrate some sources into
netbeans main repo.

Actual sources can be found on kenai: http://kenai.com/projects/nb-svuid-generator/sources
Comment 33 fommil 2009-04-20 09:16:49 UTC
Excellent @hlavki! I can work with you to make this a patch against main-golden... however don't get your hopes up, as I've been told patches are not likely to 
make the 6.7 release as it's now in "bug fix" mode.

If you want to have a stab at it yourself, have a look at my blog post http://javablog.co.uk/2009/04/11/contributing-to-netbeans/ and pay particular 
attention to the java.hints package. You'll note that you'll need to make a one line edit to layer.xml and add a few properties to Bundle.properties as well as 
write the hint... which I understand is mostly there. If you do this, don't forget to change the status to STARTED so that I don't duplicate your efforts.
Comment 34 fommil 2009-04-20 09:21:14 UTC
Having had a quick look at your code, I'm sure a lot of this is unneeded as it is already supported by the hints framework... I strongly suspect the end solution 
should be self contained.
Comment 35 fommil 2009-05-05 22:12:35 UTC
Created attachment 81592 [details]
Proposed patch against main-golden with tests. Inspiration from Michal Hlavac's plugin.
Comment 36 fommil 2009-05-05 22:19:54 UTC
I just uploaded a proposed patch for this much-desired feature: 14 votes and 8 dupes! Code freeze, smode freeze... there are test cases ;-)

The patch only offers SuppressWarning and default serialVersionUID. Contrary to popular opinion, the Java documentation for Serializable requests 
serialVersionUID on all classes... which includes abstract classes and inner classes!

@hlavki has written a plugin which does the generated piece... but there are no test cases and it would be quite a mission to fully test its output. I therefore 
recommend filing a separate issue for generated value support (based on JLS Serialization Documentation). I am more than happy to work with hlavki again to 
work on such support!
Comment 37 Jesse Glick 2009-05-06 00:17:00 UTC
As I mentioned on 2008.05.22, a SVUID generated (i.e. not just 1L) from build/classes would only be useful if you were
just _about_ to make some structural changes to the class (but had not started to do so yet) and knew that the current
version is identical to that in the last product release. The typical case for retroactive SVUID insertion is rather
different: you are busily developing all sorts of changes, suddenly notice that your app throws a serialization
exception when loading old data, and want to fix the problem. In this case, adding a SVUID generated from _current_
sources is no better than just using 1L.

I would recommend enabling the generated-SVUID hint only for Maven projects using a SNAPSHOT version; look up the
previous release in the repository and run ObjectStreamClass.lookup(Class.forName(..., false, new URLClassLoader(new
URL[] {...}))).getSerialVersionUID() on the class compiled in that release's JAR. (This also avoids the need for a
source-based reimplementation of this logic as in eu.easyedu.netbeans.svuid.service.impl.SerialVersionUIDServiceImpl.)
For Ant-based projects there is no generic way of finding the last published release short of opening a file chooser.
Comment 38 fommil 2009-05-06 09:34:18 UTC
@jglick I disagree. A serialVersionUID of 1L is useful even if a version of the class file is already in circulation and you intend to break Serialization 
compatibility (e.g. by adding new fields). It is the API designer's decision to break compatibility, not the IDE's.

I also disagree that generated values cannot be created from the current file... if the file has indeed not changed since the release, then the generated 
value will be the same. IT WOULD BE A MAJOR MISTAKE to assume that setting the serialVersionUID to equal a previous value would enforce binary 
compatibility.

In many cases, SuppressWarnings is the safest thing to do... because it will ensure a runtime exception is generated when differing versions of a class are 
being mixed by the Serialization process. That can be part of the API, that only exact versions of the class can be used. It is much more dangerous to 
presume that nothing has changed.

However, I agree that a generated serialVersionUID would be useful... but just look at the long list of people here who are asking for a SuppressWarnings 
and default value *as a start*.
Comment 39 fommil 2009-05-06 10:57:27 UTC
Incidentally, it's worth pointing out that if you discover that you have a serialVersionUID mismatch at runtime... you'll instantly know the value the JRE expects, 
because it prints it to the screen. In that case, having a "default" value (1L) inserted is halfway to the solution, because the actual value (presuming only 
structural changes) is only a Copy & Paste away!
Comment 40 hlavki 2009-05-18 22:56:33 UTC
@fommil
You are right Sam, it's mistake to assume that setting the serialVersionUID to different versions of class enforce
compatibility. But on the other hand documentation (http://java.sun.com:80/javase/6/docs/api/java/io/Serializable.html)
says that calculated svuid needn't be same for different compilers and for this reason is strongly recommended to
explicitly declare svuid value. In other words, you can have same class with different svuid calculated by different
compilers when svuid is not declared explicitly.

@jglick
As I know netbeans doesn't automatically compile java files to .class files. Of course netbeans 6.5 brings this feature
to developers but you can turn it off in several ways (e.g. maven projects have 4 options for "Compile on Save" feature.
Of course you need some resources to use SerialVersionUIDServiceImpl, but I think this is the most generic way how to
keep this feature clear in netbeans environment.

@jglick, @fommil
Yes, there are some issues (http://kenai.com/jira/browse/NB_SVUID_GENERATOR) with SerialVersionUIDServiceImpl and for
these reasons I agree with Sam's proposal to implement only hints for default svuid (1L) and SuppressWarning.
Comment 41 Jesse Glick 2009-05-18 23:48:47 UTC
@fommil: to be clear, I think adding SVUID=1L is useful in many cases, when you have no interest in (or hope of)
preserving compatibility with prior releases. I was commenting on the difficulties associated with inserting a
calculated SVUID as an alternative hint fix. And as you point out, for some use cases (e.g. wire protocols where both
the client and server are part of your project), omitting SVUID is the best policy, as the exception provides a clearer
indication of what is wrong than a half-broken deserialization; so adding a @SuppressWarnings("serial") is a good option
to offer.

@fommil: "if the file has indeed not changed since the release" then running serialver on the current class is correct,
but again, if you are adding SVUID to try to solve an _observed_ (rather than _hypothetical_) deserialization exception
then this fix does not work. I am afraid many developers would accept such a hint believing that this magic-looking
number is about to solve the bug, which it is not. A hint to insert the current calculated number would have to be
worded carefully to emphasize the conditions under which it would or would not be useful.

@hlavki: CoS projects still generate a build/classes when you run them (and BinaryForSourceQuery will if necessary
return the classes cache area). Of course if you are loading classes from a Maven release, then you definitely have a
JAR available - it is in the repository.
Comment 42 hlavki 2009-05-19 08:31:25 UTC
jglick
that means that you haven't up to date class files. So you need to enforce somehow to compile source file to provide
"correct" calculated svuid. Not to say that with SerialVersionUIDServiceImpl you have "correct" calculated svuid without
saving changes in editor.
Comment 43 twolf2919 2009-05-19 21:51:02 UTC
Dumb question from someone waiting for this: what is the status?  I got the impression that the functionality was added
as a 'hint' to NB (vs. the existing plugin).  When I create a Serializable class, I don't see such a hint.  I don't see
any "Tool" to add it either.  Maybe I'm jumping the gun?  I'm running the 5/18 daily.

thnx
Comment 44 fommil 2009-05-19 22:11:18 UTC
The patch hasn't been integrated yet. @msauer, will this make 6.7?
Comment 45 Max Sauer 2009-05-20 09:59:43 UTC
@fommil: Definitely not. UI freeze has been about a week ago, Code Freeze will be on Friday. Sorry guys. As soon as the repository will open again, I'm OK 
with integrating your patch.
Comment 46 fommil 2009-05-20 10:09:58 UTC
No problem. I'll probably create a module of all my hints that I created post-code freeze so that 6.7 users (and me!) can use them on a daily basis. Should be 
a good way to test out kenai ;-)

Incidentally, is there a module for "experimental hints" like this that get distributed as part of the standard plugin list? If so, perhaps it might be an idea to put 
it in there, presumably the rules for inclusion are less strict?
Comment 47 hlavki 2009-05-20 10:14:56 UTC
@fommil:
or you can use existing plug-in :) at
http://kenai.com/projects/nb-svuid-generator/downloads/directory/nbms
Comment 48 fommil 2009-05-20 10:22:00 UTC
@hlavki that wouldn't help with testing this implementation for bugs and also other hints I've written... but thanks for the reminder.
Comment 49 Jan Lahoda 2009-05-20 10:32:46 UTC
There is javahints module (Experimental Java Hints) in the NetBeans contrib repository:
http://hg.netbeans.org/main/contrib

This module is being regularly built and put on the Daily Update Center. You can commit any hints there, just make sure
that the module is compilable and that the hint will not break the editor (or disable the hint by default).
Comment 50 fommil 2009-05-20 10:34:11 UTC
Excellent, I'll make sure my hints are in here when 6.7 is released!
Comment 51 Jiri Kovalsky 2009-05-20 16:38:30 UTC
Sam, just FYI: the daily Development Update Center will not be registered in 6.7 FCS so people won't see the plugin
unless they manually register the development UC in their IDE.
Comment 52 fommil 2009-05-29 18:38:15 UTC
This was added to the "contrib" branch in the following commit http://hg.netbeans.org/main/contrib/rev/0bc561d1da46

Users should be able to use the build by adding the following UNSTABLE Update Center

http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastSuccessfulBuild/artifact/nbbuild/nbms/updates.xml.gz
Comment 53 Jesse Glick 2009-05-29 19:14:02 UTC
Note #1: generally you should use .../lastStableBuild/... rather than .../lastSuccessfulBuild/... for UC URLs. Test
failures can include problems with AU configuration.

Note #2: people who already have the module installed will not see your changes until the specification version is
incremented, e.g. 2.31.0 -> 2.32.0.
Comment 54 Max Sauer 2009-08-04 12:46:03 UTC
Patch integrated. Thank you all for your contributions.
---
http://hg.netbeans.org/jet-main/rev/141be701198a
http://hg.netbeans.org/jet-main/rev/178a66e9af52
Comment 55 fommil 2009-08-04 12:53:02 UTC
Awesomeness... I presume you would like me to remove the Experimental Hints version from the contrib repository? Or do you want to do that yourself?
Comment 56 Jiri Kovalsky 2009-08-04 13:06:47 UTC
This RFE was contributed by NetFIX team developer.
Comment 57 Quality Engineering 2009-08-05 06:19:04 UTC
Integrated into 'main-golden', will be available in build *200908050201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/141be701198a
User: Max Sauer <msauer@netbeans.org>
Log: #70746: Auto-generate serialVersionUID data member and value
Comment 58 _ gtzabari 2009-08-15 01:19:48 UTC
Just curious, why is the default value 1L? Shouldn't it start at 0L?
Comment 59 fommil 2009-08-15 02:32:34 UTC
It's arbitrary. 1 corresponds to "version 1".
Comment 60 hlavki 2009-08-25 08:43:10 UTC
Created attachment 86601 [details]
Path to handle anonymous classses that implements Serializable interface
Comment 61 hlavki 2009-08-25 08:44:21 UTC
I attached patch to provide hints also for anonymous classes that implements java.io.Serializable
Comment 62 Michel Graciano 2009-08-25 11:45:00 UTC
Should it be reopened or an new issue should be filed about hint for the last patch?
Comment 63 hlavki 2009-08-25 12:57:53 UTC
I think better way is to create new issue, so I created http://www.netbeans.org/issues/show_bug.cgi?id=170866
Comment 64 Jan Lahoda 2011-01-06 09:15:09 UTC
FYI: I had to merge the hint with the standard javac warning: the fixes are now attached to the standard javac warning and there is not separate hint for SVUID - see bug #193699.
Comment 65 _ gtzabari 2013-07-14 15:33:18 UTC
Restored value of component, version, OS fields. Please explain why you are changing these values for an already-fixed issue if you need to change them in the future.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo