SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
Java

Java static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your JAVA code

  • All rules 733
  • Vulnerability60
  • Bug175
  • Security Hotspot40
  • Code Smell458

  • Quick Fix 65
Filtered: 11 rules found
serialization
    Impact
      Clean code attribute
        1. "serialVersionUID" should not be declared blindly

           Code Smell
        2. Value-based objects should not be serialized

           Code Smell
        3. Files opened in append mode should not be used with "ObjectOutputStream"

           Bug
        4. "writeObject" argument must implement "Serializable"

           Bug
        5. "Serializable" inner classes of non-serializable outer classes should be "static"

           Bug
        6. Fields in non-serializable classes should not be "transient"

           Code Smell
        7. Comparators should be "Serializable"

           Code Smell
        8. "Serializable" inner classes of "Serializable" classes should be static

           Code Smell
        9. "Serializable" classes should have a "serialVersionUID"

           Code Smell
        10. The non-serializable super class of a "Serializable" class should have a no-argument constructor

           Bug
        11. Fields in a "Serializable" class should either be transient or serializable

           Code Smell

        The non-serializable super class of a "Serializable" class should have a no-argument constructor

        intentionality - logical
        reliability
        Bug
        • serialization

        Why is this an issue?

        How can I fix it?

        More Info

        Java serialization is the conversion from objects to byte streams for storage or transmission. And later, java deserialization is the reverse conversion, it reconstructs objects from byte streams.

        To make a java class serializable, this class should implement the java.io.Serializable interface directly or through its inheritance.

        import java.io.Serializable;
        
        public class NonSerializableClass {
        }
        
        public class SerializableClass implements Serializable {
        }
        
        public class OtherSerializableClass extends SerializableClass {
          // is also serializable because it is a subtype of Serializable
        }
        

        Given a serializable class, it is important to note that not all its superclasses are serializable. Eventually, its superclasses stop implementing java.io.Serializable. It could be at the end, once reaching the java.lang.Object class, or before.

        This is important because the serialization/deserialization runs through the class hierarchy of an object to decide which object fields to write or read, and applies two different logics:

        • When the class is serializable:
          • Serialization saves the class reference and the object fields of this class.
          • Deserialization instantiates a new object of this class without using a constructor, and restores the object fields of this class.
        • When the class is not serializable:
          • Serialization only saves the class reference and ignores the object fields of this class.
          • Deserialization instantiates a new object of this class using the no-argument constructor and does not restore the object fields of this class.

        So developers should pay particular attention to the non-serializable classes in the class hierarchy, because the presence of an implicit or explicit no-argument constructor is required in those classes.

        This is an example of mandatory no-argument constructors in the hierarchy of SerializableClass:

        public class NonSerializableClassWithoutConstructor {
          // after deserialization, "field1" will always be set to 42
          private int field1 = 42;
        
          // this non-serializable class has an implicit no-argument constructor
        }
        
        public class NonSerializableClass extends NonSerializableClassWithoutConstructor {
          // after deserialization, "field2" will always be set to 12 by the no-argument constructor
          private int field2;
        
          // this non-serializable class has an explicit no-argument constructor
          public NonSerializableClass() {
            field2 = 12;
          }
        
          public NonSerializableClass(int field2) {
            this.field2 = field2;
          }
        }
        
        public class SerializableClass extends NonSerializableClass implements Serializable {
          // after deserialization, "field3" will have the previously serialized value.
          private int field3;
        
          // deserialization does not use declared constructors
          public SerializableClass(int field3) {
            super(field3 * 2);
            this.field3 = field3;
          }
        }
        

        Unfortunately, there is no compilation error when a class implements java.io.Serializable and extends a non-serializable superclass without a no-argument constructor. This is an issue because, at runtime, deserialization will fail to find the required constructor.

        For example, deserialization of an instance of the following SerializableClass class, throws an InvalidClassException: no valid constructor.

        public class NonSerializableClass {
          private int field;
          // this class can not be deserialized because it does not have any implicit or explicit no-argument constructor
          public NonSerializableClass(int field) {
            this.field = field;
          }
        }
        
        public class SerializableClass extends NonSerializableClass implements Serializable {
        }
        

        This rule checks in the hierarchy of serializable classes and reports an issue when a non-serializable superclass does not have the required no-argument constructor which will produce a runtime error.

          Available In:
        • SonarQube IdeCatch issues on the fly,
          in your IDE
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories
        • SonarQube Community BuildAnalyze code in your
          on-premise CI
          Available Since
          9.1
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Developer Edition
          Available Since
          9.1

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use