19

I create a class which extends Exception class, I got this warning on Eclipse

The serializable class PhoneAlreadyExists does not declare a static final serialVersionUID field of type long

how to remove it please ?

public class PhoneAlreadyExists extends Exception {
    public PhoneAlreadyExists() {
        // TODO Auto-generated constructor stub
        super();
    }

    PhoneAlreadyExists(String message) {
        super(message);
    }

}
Tuna
  • 2,937
  • 4
  • 37
  • 61
user2059935
  • 971
  • 4
  • 12
  • 24
  • 5
    Add a `serialVersionUID` field to the class. – Perception Feb 23 '13 at 21:22
  • 1
    Its just a warning and it won't crash anything. If it really bothers you, you can suppress it by hovering over the warning and clicking the first suggestion (or whichever one says that you can suppress it). – Holden Lewis Feb 23 '13 at 21:22
  • Have a look at my answer below. That may help. – Kishan_KP Apr 04 '13 at 09:48
  • Also duplicate of [this](https://stackoverflow.com/questions/11052627/serialversionuid-field-warning-in-eclipse?s=3|92.2522) and [this](https://stackoverflow.com/questions/11881621/understanding-of-findbugs-warning-about-serialversionuid-field?s=7|78.1278) and [this](https://stackoverflow.com/questions/7823477/warning-serial-serializable-class-someclass-has-no-definition-of-serialversio?s=9|72.0586) and [this](https://stackoverflow.com/questions/6078806/inexplicable-netbeans-serializable-warning-for-nested-base-class?s=14|60.2770) and more. – Basil Bourque Jan 05 '18 at 23:15

6 Answers6

22

To change the behavior in eclipse globally: Go to Preferences->Java->Compiler->Errors/Warnings->Potential Programming Problems. There's an entry for this specific problem. You can change it for a specific project too.

That answers your question, although - I'd recommend to leave it at warning level and add the missing fields. Or add the SuppressWarnings annotation to those serializable classes that really do not need the field because they'll never be serialized.

Andreas Dolk
  • 113,398
  • 19
  • 180
  • 268
  • 1
    Thanks. Actually it's Preferences -> Java -> Compiler -> Errors/warnings -> Potential programming problems – Buffalo Mar 25 '13 at 07:23
  • Thanks for the correction! I've updated my answer with the correct path. – Andreas Dolk Mar 26 '13 at 07:05
  • 1
    Funny how the most useful/to the point answers are always left behind, yours should be the accepted answer. – Buffalo Mar 27 '13 at 14:00
  • Note that you get this warning when deriving an anonymous type from some serializable type - even if the supertype _has its own @SuppressWarnings("serial")!!_). E.g., when using Guava's TypeToken. (Eclipse 4.4.2.) I suppose I _could_ annotate the site of the new anonymous type ... but it's a PITA and I'd rather turn this nearly useless warning off altogether. – davidbak Aug 04 '15 at 21:41
  • Do **not** just ignore warnings. In 99% of cases, they are correctly warning you about a problem. Rather fix the root cause instead. – Has QUIT--Anony-Mousse Jul 19 '17 at 11:19
  • 1
    @Anony-Mousse Generally I agree with you, but unless you are serializing your exceptions, sending them over RMI/CORBA or storing them to disk, most people will not encounter problems with exception serialization in most domains. If you are in a domain where you will be affected, you (should) _know_. The 99% will not see issues in their web apps due to this. That's why it should be possible to globally disable this for a project. Too bad there is no globally available fix like `.eslintrc` for Java. – oligofren Oct 26 '18 at 13:33
  • @oligofren: just add the serial number. That is not at all harder (press Ctrl+1 in Eclipse). And that actually is a **proper solution** for the warning, rather than *ignoring* the cause. Why ignore when there is a one-time auto-generateable fix? – Has QUIT--Anony-Mousse Oct 26 '18 at 18:15
11

Add an annotation @SuppressWarnings("serial") on your class, to ignore that warning

Arsen Alexanyan
  • 3,061
  • 5
  • 25
  • 45
  • 2
    Or just *resolve the warning correctly*. It's usually better than ignoring it, even if it is 4 lines of code (including JavaDoc, of course - otherwise it's just 1) – Has QUIT--Anony-Mousse Feb 24 '13 at 09:00
  • 2
    Of course, but usually we needn't to define serial version, therefore this is quick solution for the problem. – Arsen Alexanyan Feb 24 '13 at 09:02
  • 2
    It's not really quicker. Java IDEs can generate serial version fields using the "quick fix" function. E.g. eclipse. – Has QUIT--Anony-Mousse Feb 24 '13 at 09:03
  • Nice suggestion I haven't tried it yet with quick fix :) – Arsen Alexanyan Feb 24 '13 at 09:04
  • Does someone have a like about this? I'm wondering if there are other types of "serial" warnings that may be suppressed or if this is the only case. – jcalfee314 Mar 11 '14 at 13:40
  • 2
    @Anony-Mousse every line of code represents intent. If you do not intend the object to be serialized, and you add code to support contrary, you are writing incoherent code. If we adhere to all possible "3 lines of code" changes, the intentional part of your code will end up being minority of your actual code, which is dangerous if you want to write code that you want to be able to come back to later. It is compiler's, and fragile base class, and typeclass's responsibility to take care of spicing up your classes, not your specific class itself. – Dmytro Jul 15 '17 at 01:32
  • 1
    @Dmitry If you don't intend the class to be serializable, then don't implement the `Serializable` interface! It's not the `serialVersionUID` field that *causes* the inconsistency, nor will ignoring the problem solve it. All this field does is help recognize deserialization issues when a class definition changes. Adding it will not "enable" serialization, and ignoring the warning will not prevent serialization. – Has QUIT--Anony-Mousse Jul 16 '17 at 07:48
  • @Anony-Mousse As the original poster pointed out, this annoyance can happen when you extend a class that is serializable, which is beyond your control. If a programmer is confident that no `PhoneAlreadyExists` instance will ever be serialized, then the `@SuppressWarnings` annotation is entirely approrpriate. – cayhorstmann Mar 19 '18 at 16:08
  • Which gains you nothing compared to just having your IDE generate a serial. It won't be detected as a mistake - the class will still implement serializable. – Has QUIT--Anony-Mousse Mar 19 '18 at 19:17
  • i generated a serial version and it still says 'The serializable class Window does not declare a static final serialVersionUID field of type long' lmao – madladzen Apr 13 '20 at 13:03
9

You need to declare a static final serialVersionUID field of type long.

Look up the Serializable API of Java. Exceptions must implement Serializable, and Serializable classes must have a serialVersionUID:

public static final long serialVersionUID = 1L;

Whenever you make incompatible changes to the class, increment this version.

Has QUIT--Anony-Mousse
  • 76,138
  • 12
  • 138
  • 194
2

To ignore the warning "The serializable class ClASSNAME does not declare a static final serialVersionUID......" do the following inside eclipse*:

  1. Click Window-Preferences-Java-Compiler-Errors/Warnings
  2. Click on "Potential Programming Problems"
  3. Scroll down to "Serializable class without serialVersionUID"
  4. Choose "Ignore"
  5. Click Apply
  6. Click OK

Save and close your eclipse IDE When you reopen eclipse, these specific warnings should no longer be listed.

*For this example solution I'm using Eclipse IDE for Java Developers - Version: Mars.2 Release (4.5.2)

1

just add this code @SuppressWarnings("serial") above your public class PhoneAlreadyExists extends Exception { line

ramesh
  • 11
  • 3
1

It is best to add the serialversionUID in most cases, but eclipse gives the warning on all swing derived classes, which will never be serialized. I tried changing the setting at preferences->Java -> Compiler -> Errors/warnings -> Potential programming problems, but it had no effect. So I guess the best solution would be to suppress the warning on each class that will never be serialized; or grit your teeth and ignore the warning.

Dave Neuendorf
  • 11
  • 1