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.
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.
See http://serialversion.netbeans.org/
I can't access http://serialversion.netbeans.org/. Why?
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.
*** Issue 95708 has been marked as a duplicate of this issue. ***
*** Issue 58917 has been marked as a duplicate of this issue. ***
*** Issue 100366 has been marked as a duplicate of this issue. ***
you could also place the serial ID in the template for a class, as mentioned in #100366...
the option probably better belongs in the 'Generate Code...' action.
What about having some sort of action that automatically regenerates serialVersionUID when the signature of the class file changed?
*** Issue 77345 has been marked as a duplicate of this issue. ***
*** Issue 118255 has been marked as a duplicate of this issue. ***
Increasing priority because of duplicate issues. Please note that this issue is also related to #85530
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.
*** Issue 117990 has been marked as a duplicate of this issue. ***
*** Issue 85530 has been marked as a duplicate of this issue. ***
7 dupes now... is anybody working on adding this to 6.1? It should be really trivial to add a code fix.
cannot access http://serialversion.netbeans.org/ as well... no plugin available for this functionality?
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.
*** Issue 57293 has been marked as a duplicate of this issue. ***
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).
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).
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.)
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).
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.
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
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).
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
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!
+1 to last comment
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...
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?
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
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.
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.
Created attachment 81592 [details] Proposed patch against main-golden with tests. Inspiration from Michal Hlavac's plugin.
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!
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.
@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*.
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!
@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.
@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.
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.
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
The patch hasn't been integrated yet. @msauer, will this make 6.7?
@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.
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?
@fommil: or you can use existing plug-in :) at http://kenai.com/projects/nb-svuid-generator/downloads/directory/nbms
@hlavki that wouldn't help with testing this implementation for bugs and also other hints I've written... but thanks for the reminder.
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).
Excellent, I'll make sure my hints are in here when 6.7 is released!
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.
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
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.
Patch integrated. Thank you all for your contributions. --- http://hg.netbeans.org/jet-main/rev/141be701198a http://hg.netbeans.org/jet-main/rev/178a66e9af52
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?
This RFE was contributed by NetFIX team developer.
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
Just curious, why is the default value 1L? Shouldn't it start at 0L?
It's arbitrary. 1 corresponds to "version 1".
Created attachment 86601 [details] Path to handle anonymous classses that implements Serializable interface
I attached patch to provide hints also for anonymous classes that implements java.io.Serializable
Should it be reopened or an new issue should be filed about hint for the last patch?
I think better way is to create new issue, so I created http://www.netbeans.org/issues/show_bug.cgi?id=170866
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.
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.