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: 55 rules found
pitfall
    Impact
      Clean code attribute
        1. Functions should not be defined with a variable number of arguments

           Code Smell
        2. Literal suffixes should be upper case

           Code Smell
        3. Class members annotated with "@VisibleForTesting" should not be accessed from production code

           Code Smell
        4. Avoid using boxed "Boolean" types directly in boolean expressions

           Code Smell
        5. "serialVersionUID" should not be declared blindly

           Code Smell
        6. Spring beans should be considered by "@ComponentScan"

           Code Smell
        7. "compareTo" should not be overloaded

           Bug
        8. "iterator" should not return "this"

           Bug
        9. Secure random number generators should not output predictable values

           Vulnerability
        10. Getters and setters should access the expected fields

           Bug
        11. Asserts should not be used to check the parameters of a public method

           Code Smell
        12. "Stream.peek" should be used with caution

           Code Smell
        13. Raw types should not be used

           Code Smell
        14. Constructor injection should be used instead of field injection

           Bug
        15. Threads should not be started in constructors

           Code Smell
        16. Conditionally executed code should be reachable

           Bug
        17. Whitespace and control characters in literals should be explicit

           Code Smell
        18. "null" should not be returned from a "Boolean" method

           Code Smell
        19. "Thread" should not be used where a "Runnable" argument is expected

           Code Smell
        20. Inner class calls to super class methods should be unambiguous

           Code Smell
        21. "private" and "final" methods that don't access instance data should be "static"

           Code Smell
        22. "ResultSet.isLast()" should not be used

           Code Smell
        23. "static" members should be accessed statically

           Code Smell
        24. Wildcard imports should not be used

           Code Smell
        25. Child class methods named for parent class methods should be overrides

           Bug
        26. Class names should not shadow interfaces or superclasses

           Code Smell
        27. Classes named like "Exception" should extend "Exception" or a subclass

           Code Smell
        28. "java.time" classes should be used for dates and times

           Code Smell
        29. Classes extending java.lang.Thread should provide a specific "run" behavior

           Bug
        30. Try-with-resources should be used

           Code Smell
        31. Comparators should be "Serializable"

           Code Smell
        32. "readResolve" methods should be inheritable

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

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

           Code Smell
        35. Boolean checks should not be inverted

           Code Smell
        36. Related "if/else if" statements should not have the same condition

           Bug
        37. "switch" statements and expressions should not be nested

           Code Smell
        38. Constructors should only call non-overridable methods

           Code Smell
        39. "NullPointerException" should not be explicitly thrown

           Code Smell
        40. Package declaration should match source file directory

           Code Smell
        41. "Collections.EMPTY_LIST", "EMPTY_MAP", and "EMPTY_SET" should not be used

           Code Smell
        42. Generic wildcard types should not be used in return types

           Code Smell
        43. Private fields only used as local variables in methods should become local variables

           Code Smell
        44. "StringBuilder" and "StringBuffer" should not be instantiated with a character

           Bug
        45. Octal values should not be used

           Code Smell
        46. "for" loop stop conditions should be invariant

           Code Smell
        47. Classes and enums with private members should have a constructor

           Code Smell
        48. Non-constructor methods should not have the same name as the enclosing class

           Code Smell
        49. Methods should not be named "tostring", "hashcode" or "equal"

           Bug
        50. Control structures should use curly braces

           Code Smell
        51. Classes from "sun.*" packages should not be used

           Code Smell
        52. Future keywords should not be used as names

           Code Smell
        53. The signature of "finalize()" should match that of "Object.finalize()"

           Bug
        54. Only static class initializers should be used

           Code Smell
        55. Local variables should not shadow class fields

           Code Smell

        Generic wildcard types should not be used in return types

        intentionality - clear
        maintainability
        Code Smell
        • pitfall

        Why is this an issue?

        How can I fix it?

        More Info

        A return type containing wildcards cannot be narrowed down in any context. This indicates that the developer’s intention was likely something else.

        The core problem lies in type variance. Expressions at an input position, such as arguments passed to a method, can have a more specific type than the type expected by the method, which is called covariance. Expressions at an output position, such as a variable that receives the return result from a method, can have a more general type than the method’s return type, which is called contravariance. This can be traced back to the Liskov substitution principle.

        In Java, type parameters of a generic type are invariant by default due to their potential occurrence in both input and output positions at the same time. A classic example of this is the methods T get() (output position) and add(T element) (input position) in interface java.util.List. We could construct cases with invalid typing in List if T were not invariant.

        Wildcards can be employed to achieve covariance or contravariance in situations where the type parameter appears in one position only:

        • <? extends Foo> for covariance (input positions)
        • <? super Foo> for contravariance (output positions)

        However, covariance is ineffective for the return type of a method since it is not an input position. Making it contravariant also has no effect since it is the receiver of the return value which must be contravariant (use-site variance in Java). Consequently, a return type containing wildcards is generally a mistake.

          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