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: 13 rules found
architecture
    Impact
      Clean code attribute
        1. Circular dependencies between classes across packages should be resolved

           Code Smell
        2. Circular dependencies between classes in the same package should be resolved

           Code Smell
        3. The Singleton design pattern should be used with care

           Code Smell
        4. Methods should not perform too many tasks (aka Brain method)

           Code Smell
        5. Classes should not depend on an excessive number of classes (aka Monster Class)

           Code Smell
        6. Cognitive Complexity of methods should not be too high

           Code Smell
        7. Inner classes should not have too many lines of code

           Code Smell
        8. Methods should not be too complex

           Code Smell
        9. Classes should not have too many methods

           Code Smell
        10. Methods should not have too many lines

           Code Smell
        11. Classes should not be coupled to too many other classes

           Code Smell
        12. Inheritance tree of classes should not be too deep

           Code Smell
        13. Files should not have too many lines of code

           Code Smell

        The Singleton design pattern should be used with care

        adaptability - modular
        maintainability
        Code Smell
        • architecture
        • design

        The Singleton design pattern is a creational pattern. It ensures that only one class instance is created and provides a global point of access to it. There are several ways to implement a Singleton in Java, and the debate about the best approach has yet to be settled.

        This rule marks all classes that are considered as Singletons, regardless of how they are implemented. This helps developers identify where in the code Singletons are used. Singletons should be reviewed to confirm whether a Singleton is truly necessary and whether the selected implementation is the most suitable for the context.

        Every Singleton implementation has its advantages and disadvantages. This rule exists to bring attention to them so that informed decisions can be made.

        Why is this an issue?

        While the Singleton pattern can be useful in certain situations, overusing it can have several drawbacks:

        • Tight coupling: The Singleton pattern can create tight coupling between the Singleton class and other classes that use it, making the code difficult to maintain and modify.
        • Global state: The Singleton pattern can create a global state, making it difficult to manage the state of the application and leading to unexpected behavior.
        • Testing: The Singleton pattern can make it difficult to test classes that depend on the Singleton, as the Singleton cannot be easily substituted with a mock object.
        • Scalability: The Singleton pattern can make it difficult to scale an application, as it can create a bottleneck if multiple threads try to access the Singleton concurrently.
        • Dependency injection: The Singleton pattern can make it difficult to use dependency injection frameworks, as the Singleton instance is usually created statically.

        In general, the Singleton pattern should be used sparingly and only in situations where it provides a clear benefit over other patterns or approaches. It is important to consider the drawbacks and tradeoffs of using the Singleton pattern before incorporating it into an application.

        What is the potential impact?

        Enum Implementation

        public enum EnumSingleton {
        
            INSTANCE;
        
            private EnumSingleton() {
                // Initialization code here...
            }
        }
        

        Advantages:

        This implementation is thread-safe by default because the initialization of an Enum value is guaranteed to be thread-safe and atomic.

        The Enum Singleton implementation allows for lazy initialization while also providing thread-safety guarantees.

        Bill Pugh Implementation

        public class BillPughSingleton {
        
            private BillPughSingleton(){}
        
            private static class SingletonHelper {
                private static final BillPughSingleton INSTANCE = new BillPughSingleton();
            }
        
            public static BillPughSingleton getInstance() {
                return SingletonHelper.INSTANCE;
            }
        }
        

        Advantages:

        The instance is created only at the first call of the getInstance() method.

        This implementation is thread-safe.

        Thread Safe Implementation

        public class ThreadSafeSingleton {
        
            private static ThreadSafeSingleton instance;
        
            private ThreadSafeSingleton(){}
        
            public static synchronized ThreadSafeSingleton getInstance() {
                if (instance == null) {
                    instance = new ThreadSafeSingleton();
                }
                return instance;
            }
        }
        

        Advantage:

        This implementation is thread-safe.

        Disadvantage:

        It reduces the performance because of the cost associated with the synchronized method. To avoid this extra overhead every time, double-checked locking principle should be used.

        Static Block Initialization Implementation

        public class StaticBlockSingleton {
        
            private static StaticBlockSingleton instance;
        
            private StaticBlockSingleton(){}
        
            static {
                try {
                    instance = new StaticBlockSingleton();
                } catch (Exception e) {
                    throw new RuntimeException("Exception while creating singleton instance");
                }
            }
        
            public static StaticBlockSingleton getInstance() {
                return instance;
            }
        }
        

        Advantage:

        Compared to the Eager Initialization, this implementation provides options for exception handling.

        Disadvantage:

        The instance is created even if it’s never used, like for the Eager Initialization implementation.

        Eager Initialization Implementation

        public class EagerInitializedSingleton {
        
            private static final EagerInitializedSingleton instance = new EagerInitializedSingleton();
        
            private EagerInitializedSingleton() {}
        
            public static EagerInitializedSingleton getInstance() {
                return instance;
            }
        }
        

        Advantage:

        This implementation is thread-safe, as the instance variable is initialized when the class is loaded.

        Disadvantages:

        The instance is created even if it’s never used, which can be wasteful in terms of memory usage. However, if the Singleton is expected to be used frequently or is not too memory-intensive, Eager Initialization can be a good choice.

        This implementation doesn’t provide any options for exception handling.

        Lazy Initialization Implementation

        public class LazyInitializedSingleton {
        
            private static LazyInitializedSingleton instance;
        
            private LazyInitializedSingleton(){}
        
            public static LazyInitializedSingleton getInstance() {
                if (instance == null) {
                    instance = new LazyInitializedSingleton();
                }
                return instance;
            }
        }
        

        Advantage:

        This implementation works fine in the case of the single-threaded environment.

        Disadvantage:

        This implementation is not thread-safe if multiple threads are at the same time in the if condition.

        Public Static Field Implementation

        public class PublicStaticSingleton {
        
            public static final PublicStaticSingleton INSTANCE = new PublicStaticSingleton();
        
            private PublicStaticSingleton() {}
        }
        

        Advantage:

        This implementation is thread-safe.

        Disadvantage:

        This implementation does not allow lazy initialization: the constructor runs as soon as the class is initialized.

          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
          10.1
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Developer Edition
          Available Since
          10.1

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use