> ## Documentation Index
> Fetch the complete documentation index at: https://docs.codeant.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Java - 1

> Learn about Java Anti-Patterns and How they help you write better code, and avoid common pitfalls.

<AccordionGroup>
  <Accordion title="this.getClass().getResource() should not be used with relative paths in non-final classes">
    <div class="paragraph">
      <p>Any extensible class might have subclasses located in a different package. When that happens, the use of \`this.getClass().getResource with a relative path would mean that the resource isn’t found for the child class.</p>
    </div>

    <div class="paragraph">
      <p>Instead, use an absolute path or make the class final\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class MyClass {

      private URL url = null;

      public MyClass(){
      this.url = this.getClass().getResource("file.txt");  // Noncompliant
      }
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Lambdas should be replaced with method references">
    <div class="paragraph">
      <p>Method or constructor references are more readable than lambda expressions in many situations, and may therefore be preferred.</p>
    </div>

    <div class="paragraph">
      <p>However, method references are sometimes less concise than lambdas.
      In such cases, it might be preferrable to keep the lambda expression for better readability.
      Therefore, this rule only raises issues on lambda expressions where the replacement method reference is shorter.</p>
    </div>

    <div class="paragraph">
      <p>This rule is automatically disabled when the project’s sonar.java.source is lower than 8, as lambda expressions were introduced in Java 8.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      class A {
      void process(List<A> list) {
      list.stream()
        .filter(myListValue -> myListValue instanceof B)     // Noncompliant
        .map(listValueToMap -> (B) listValueToMap)           // Noncompliant
        .map(bValueToMap -> bValueToMap.<String>getObject()) // Noncompliant
        .forEach(o -> System.out.println(o));                // Noncompliant
      }
      }

      class B extends A {
      <T> T getObject() {
      return null;
      }
      }
      ```

      ```java Fix theme={null}
      class A {
      void process(List<A> list) {
      list.stream()
        .filter(B.class::isInstance)   // Compliant
        .map(B.class::cast)            // Compliant
        .map(B::<String>getObject)     // Compliant
        .forEach(System.out::println); // Compliant
      }
      }

      class B extends A {
      <T> T getObject() {
      return null;
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Thread should not be used where a Runnable argument is expected">
    <div class="paragraph">
      <p>The semantics of Thread and Runnable are different, and while it is technically correct to use Thread where a Runnable is expected, it is a bad practice to do so.</p>
    </div>

    <div class="paragraph">
      <p>The crux of the issue is that Thread is a larger concept than Runnable.
      A Runnable represents a task.
      A Thread represents a task and its execution management (ie: how it should behave when started, stopped, resumed, …​).
      It is both a task and a lifecycle management.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public static void main(String[] args) {
      Thread runnable = new Thread() {
      	@Override
      	public void run() { /* ... */ }
      };
      new Thread(runnable).start();  // Noncompliant
      }
      ```

      ```java Fix theme={null}
      public static void main(String[] args) {
      Runnable runnable = new Runnable() {
      	@Override
      	public void run() { /* ... */ }
      };
      new Thread(runnable).start();
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Intermediate Stream methods should not be left unused">
    <div class="paragraph">
      <p>There are two types of stream operations: intermediate operations, which return another stream, and terminal operations, which return something other than a stream. Intermediate operations are lazy, meaning they aren’t actually executed until and unless a terminal stream operation is performed on their results. Consequently, if the result of an intermediate stream operation is not fed to a terminal operation, it serves no purpose, which is almost certainly an error.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      widgets.stream().filter(b -> b.getColor() == RED); // Noncompliant
      ```

      ```java Fix theme={null}
      int sum = widgets.stream()
                        .filter(b -> b.getColor() == RED)
                        .mapToInt(b -> b.getWeight())
                        .sum();
      Stream<Widget> pipeline = widgets.stream()
                                   .filter(b -> b.getColor() == GREEN)
                                   .mapToInt(b -> b.getWeight());
      sum = pipeline.sum();
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="read(byte[],int,int) should be overridden">
    <div class="paragraph">
      <p>When directly subclassing \`java.io.InputStream or java.io.FilterInputStream, the only requirement is that you implement the method read(). However most uses for such streams don’t read a single byte at a time and the default implementation for read(byte\[],int,int) will call read(int) for every single byte in the array which can create a lot of overhead and is utterly inefficient. It is therefore strongly recommended that subclasses provide an efficient implementation of read(byte\[],int,int).</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when a direct subclass of java.io.InputStream or java.io.FilterInputStream doesn’t provide an override of read(byte\[],int,int)\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class MyInputStream extends java.io.InputStream {
      private FileInputStream fin;

      public MyInputStream(File file) throws IOException {
      fin = new FileInputStream(file);
      }

      @Override
      public int read() throws IOException {
      return fin.read();
      }
      }
      ```

      ```java Fix theme={null}
      public class MyInputStream extends java.io.InputStream {
      private FileInputStream fin;

      public MyInputStream(File file) throws IOException {
      fin = new FileInputStream(file);
      }

      @Override
      public int read() throws IOException {
      return fin.read();
      }

      @Override
      public int read(byte[] b, int off, int len) throws IOException {
      return fin.read(b, off, len);
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Characters should not be appended as Strings">
    <div class="paragraph">
      <p>It’s slightly more efficient to append single characters to <code>StringBuffer and StringBuilder instances as chars, than as Strings. That is, it’s more efficient to put a single char</code> in single quotes, rather than double quotes.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      StringBuilder sb = new StringBuilder();

      sb.append("a"); // Noncompliant
      ```

      ```java Fix theme={null}
      StringBuilder sb = new StringBuilder();

      sb.append('a'); // Noncompliant
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Synchronized classes Vector, Hashtable, Stack and StringBuffer should not be used">
    <div class="paragraph">
      <p>Early classes of the Java API, such as Vector, Hashtable and StringBuffer, were synchronized to make them thread-safe.
      However, synchronization has a significant negative impact on performance, even when using these collections from a single thread.</p>
    </div>

    <div class="paragraph">
      <p>It is often best to use their non-synchronized counterparts:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>ArrayList or LinkedList instead of Vector</p>
        </li>

        <li>
          <p>Deque instead of Stack</p>
        </li>

        <li>
          <p>HashMap instead of Hashtable</p>
        </li>

        <li>
          <p>StringBuilder instead of StringBuffer</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>Even when used in synchronized contexts, you should think twice before using their synchronized counterparts, since their usage can be costly.
      If you are confident the usage is legitimate, you can safely ignore this warning.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Vector<Cat> cats = new Vector<>();
      ```

      ```java Fix theme={null}
      ArrayList<Cat> cats = new ArrayList<>();
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="java.nio.Files#delete should be preferred">
    <div class="paragraph">
      <p>When <code>java.io.File#delete fails, this boolean method simply returns false with no indication of the cause. On the other hand, when java.nio.file.Files#delete fails, this void method returns one of a series of exception types to better indicate the cause of the failure. And since more information is generally better in a debugging situation, java.nio.file.Files#delete</code> is the preferred option.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public void cleanUp(Path path) {
      File file = new File(path);
      if (!file.delete()) {  // Noncompliant
      //...
      }
      }
      ```

      ```java Fix theme={null}
      public void cleanUp(Path path) throws NoSuchFileException, DirectoryNotEmptyException, IOException {
      Files.delete(path);
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="AssertJ methods setting the assertion context should come before an assertion">
    <div class="paragraph">
      <p>Describing, setting error message or adding a comparator in <a href="https://assertj.github.io/doc/">AssertJ</a> must be done before calling the assertion, otherwise, settings will not be taken into account.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when one of the method (with all similar methods):</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>\`as</p>
        </li>

        <li>
          <p>describedAs</p>
        </li>

        <li>
          <p>withFailMessage</p>
        </li>

        <li>
          <p>overridingErrorMessage</p>
        </li>

        <li>
          <p>usingComparator</p>
        </li>

        <li>
          <p>usingElementComparator</p>
        </li>

        <li>
          <p>extracting</p>
        </li>

        <li>
          <p>filteredOn\`</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>is called without calling an AssertJ assertion afterward.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      assertThat(actual).isEqualTo(expected).as("Description"); // Noncompliant
      assertThat(actual).isEqualTo(expected).withFailMessage("Fail message"); // Noncompliant
      assertThat(actual).isEqualTo(expected).usingComparator(new CustomComparator()); // Noncompliant
      ```

      ```java Fix theme={null}
      assertThat(actual).as("Description").isEqualTo(expected);
      assertThat(actual).withFailMessage("Fail message").isEqualTo(expected);
      assertThat(actual).usingComparator(new CustomComparator()).isEqualTo(expected);
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Octal and hexadecimal escape sequences should be terminated">
    <div class="paragraph">
      <p>There is potential for confusion if an octal or hexadecimal escape sequence is immediately followed by other characters. Instead, such sequences should be terminated by either:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>The start of another escape sequence.</p>
        </li>

        <li>
          <p>The end of the string.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      String hasHex = "\x41g";  // Noncompliant
      String hasOct = '\141t'; // Noncompliant
      ```

      ```java Fix theme={null}
      String hasHex = "\x41" + "g"; // Compliant - terminated by end of literal
      String hasOct = "\x41\x67"; // Compliant - terminated by another escape
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Array designators [] should be located after the type in method signatures">
    <div class="paragraph">
      <p>Placing the array designators \[] after the type helps maintain backward compatibility with older versions of the Java SE platform.
      This syntax contributes to better readability as it becomes easier to distinguish between array types and non-array types.
      It helps convey the intention of the method to both the developer implementing it and the developer using it.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class Cube {
      private int magicNumbers[] = { 42 };      // Noncompliant
      public int getVector()[] { /* ... */ }    // Noncompliant
      public int[] getMatrix()[] { /* ... */ }  // Noncompliant
      }
      ```

      ```java Fix theme={null}
      public class Cube {
      private int[] magicNumbers = { 42 };      // Compliant
      public int[] getVector() { /* ... */ }    // Compliant
      public int[][] getMatrix() { /* ... */ }  // Compliant
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Messages output from a servlet catch block should be invariable">
    <div class="paragraph">
      <p>Clear and communicative error messages help people understand what went wrong and how to correct the problem. However, care must be taken with \`Servlet error messages because they could expose sensitive information to an attacker. Even sending the user’s own data back to him in an error message could be risky; you never know who might catch a glimpse of the screen.</p>
    </div>

    <div class="paragraph">
      <p>This rule checks that the strings used in servlet responses made from catch blocks don’t change from call to call. Ideally, such strings would be private static final\`, but that is not enforced by this rule. Logging messages are ignored by this rule.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class MyServlet extends HttpServlet {
      protected void doPost(HttpServletRequest request, HttpServletResponse response) 
          throws ServletException, IOException {
      String login = null;
      String pword
      try {
        login =  login = request.getParameter("login");
        pword = request.getParameter("password");
        // ...
      }
      catch (LoginFailureException ex) {
        LOGGER.log(Level.INFO, "Login failure for " + 
                login + ", " + pword);  // Compliant, but not a good idea
        request.setAttribute("error", 
                "Login failed for " + login + // Noncompliant; attacker now knows valid or nearly-valid login
                        " with password " + pword);  // Noncompliant; attacker now knows valid or nearly-valid password
        request.setAttribute("message", ex.getMessage()); // Noncompliant; could contain sensitive data
        getServletContext().getRequestDispatcher("/ErrorPage.jsp")
                .forward(request, response);
      ```

      ```java Fix theme={null}
      public class MyServlet extends HttpServlet {
      protected void doPost(HttpServletRequest request, HttpServletResponse response) 
          throws ServletException, IOException {
      String login = null;
      String pword
      try {
        login =  login = request.getParameter("login");
        pword = request.getParameter("password");
        // ...
      }
      catch (LoginFailureException ex) {
        LOGGER.log(Level.INFO, "Login failure for " + login);  // Much better
        request.setAttribute("error", "Login failed");
        getServletContext().getRequestDispatcher("/ErrorPage.jsp")
                .forward(request, response);
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Inappropriate regular expressions should not be used">
    <div class="paragraph">
      <p>Regular expressions are powerful but tricky, and even those long used to using them can make mistakes.</p>
    </div>

    <div class="paragraph">
      <p>The following should not be used as regular expressions:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>\`. - matches any single character. Used in replaceAll, it matches <em>everything</em></p>
        </li>

        <li>
          <p>| - normally used as an option delimiter. Used stand-alone, it matches the space between characters</p>
        </li>

        <li>
          <p>File.separator\` - matches the platform-specific file path delimiter. On Windows, this will be taken as an escape character</p>
        </li>
      </ul>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      String str = "/File|Name.txt";

      String clean = str.replaceAll(".",""); // Noncompliant; probably meant to remove only dot chars, but returns an empty string
      String clean2 = str.replaceAll("|","_"); // Noncompliant; yields _/_F_i_l_e_|_N_a_m_e_._t_x_t_
      String clean3 = str.replaceAll(File.separator,""); // Noncompliant; exception on Windows

      String clean4 = str.replaceFirst(".",""); // Noncompliant;
      String clean5 = str.replaceFirst("|","_"); // Noncompliant; 
      String clean6 = str.replaceFirst(File.separator,""); // Noncompliant;
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Spring components should use constructor injection">
    <div class="paragraph">
      <p>Spring \`@Controller, @Service, and @Repository classes are singletons by default, meaning only one instance of the class is ever instantiated in the application. Typically such a class might have a few static members, such as a logger, but all non-static members should be managed by Spring and supplied via constructor injection rather than by field injection.</p>
    </div>

    <div class="paragraph">
      <p>This rule raise an issue when any non-static\` member of a Spring component has an injection annotation.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @Controller
      public class HelloWorld {

      @Autowired
      private String name = null; // Noncompliant

      }
      ```

      ```java Fix theme={null}
      @Controller
      public class HelloWorld {

      private String name = null;

      HelloWorld(String name) {
      this.name = name;
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="The signature of finalize() should match that of Object.finalize()">
    <div class="paragraph">
      <p>\`Object.finalize() is called by the Garbage Collector at some point after the object becomes unreferenced.</p>
    </div>

    <div class="paragraph">
      <p>In general, overloading Object.finalize() is a bad idea because:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>The overload may not be called by the Garbage Collector.</p>
        </li>

        <li>
          <p>Users are not expected to call Object.finalize() and will get confused.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>But beyond that it’s a terrible idea to name a method "finalize" if it doesn’t actually override Object.finalize()\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public int finalize(int someParameter) {        // Noncompliant
      /* ... */
      }
      ```

      ```java Fix theme={null}
      public int someBetterName(int someParameter) {  // Compliant
      /* ... */
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="ThreadGroup should not be used">
    <div class="paragraph">
      <p>The ThreadGroup class contains many deprecated methods like allowThreadSuspension, resume, stop, and suspend.
      Also, some of the non-deprecated methods are obsolete or not thread-safe, and still others are insecure (activeCount, enumerate).
      For these reasons, any use of ThreadGroup is suspicious and should be avoided.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      class NetworkHandler {

      void startThreadInGroup(ThreadGroup tg) { // Noncompliant, use an ExecutorService instead, which is more secure
      Thread thread = new Thread(tg, "controller");
      thread.start();
      }

      }
      ```

      ```java Fix theme={null}
      class NetworkHandler {

      void handleThreadsProperly() {
      ThreadFactory threadFactory = Executors.defaultThreadFactory();
      ThreadPoolExecutor executorPool = new ThreadPoolExecutor(3, 10, 5, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(2), threadFactory);
      for (int i = 0; i < 10; i++) {
        executorPool.execute(new Thread("Job: " + i));
      }
      executorPool.shutdown();
      }

      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Classes extending java.lang.Thread should provide a specific run behavior">
    <div class="paragraph">
      <p>The default implementation of java.lang.Thread 's run will only perform a task passed as a Runnable.
      If no Runnable has been provided at construction time, then the thread will not perform any action.</p>
    </div>

    <div class="paragraph">
      <p>When extending java.lang.Thread, you should override the run method or pass a Runnable target to the constructor of java.lang.Thread.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class MyThread extends Thread { // Noncompliant
      public void doSomething() {
      System.out.println("Hello, World!");
      }
      }
      ```

      ```java Fix theme={null}
      public class MyThread extends Thread {
      @Override
      public void run() {
      System.out.println("Hello, World!");
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="compareTo arguments should be cast without testing">
    <div class="paragraph">
      <p>Perhaps counter-intuitively, a <code>compareTo method is <em>expected</em> to throw a NullPointerException if passed a null argument, and a ClassCastException</code> if the argument is of the wrong type. So there’s no need to null-test or type-test the argument.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public int compareTo(Object obj) {

      if (obj == null) { // Noncompliant
      return -1;
      }
      if (! obj instanceof MyClass.class) { // Noncompliant
      return -1;
      }

      MyObject myObj = (MyObject) obj;
      // ...
      }
      ```

      ```java Fix theme={null}
      public int compareTo(Object obj) {

      MyObject myObj = (MyObject) obj;
      // ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="String offset-based methods should be preferred for finding substrings from offsets">
    <div class="paragraph">
      <p>Looking for a given substring starting from a specified offset can be achieved by such code: \`str.substring(beginIndex).indexOf(char1). This works well, but it creates a new String for each call to the substring method. When this is done in a loop, a lot of Strings are created for nothing, which can lead to performance problems if str is large.</p>
    </div>

    <div class="paragraph">
      <p>To avoid performance problems, String.substring(beginIndex) should not be chained with the following methods:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>indexOf(int ch)</p>
        </li>

        <li>
          <p>indexOf(String str)</p>
        </li>

        <li>
          <p>lastIndexOf(int ch)</p>
        </li>

        <li>
          <p>lastIndexOf(String str)</p>
        </li>

        <li>
          <p>startsWith(String prefix)</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>For each of these methods, another method with an additional parameter is available to specify an offset.</p>
    </div>

    <div class="paragraph">
      <p>Using these methods will avoid the creation of additional String\` instances.
      For indexOf methods, adjust the returned value by subtracting the substring index parameter to obtain the same result.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      str.substring(beginIndex).indexOf(char1); // Noncompliant; a new String is going to be created by "substring"
      ```

      ```java Fix theme={null}
      str.indexOf(char1, beginIndex) - beginIndex; // index for char1 not found is (-1-beginIndex)
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Consumed Stream pipelines should not be reused">
    <div class="paragraph">
      <p>Stream operations are divided into intermediate and terminal operations, and are combined to form stream pipelines. After the terminal operation is performed, the stream pipeline is considered consumed, and cannot be used again. Such a reuse will yield unexpected results.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Stream<Widget> pipeline = widgets.stream().filter(b -> b.getColor() == RED);
      int sum1 = pipeline.sum();
      int sum2 = pipeline.mapToInt(b -> b.getWeight()).sum(); // Noncompliant
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Test assertions should include messages">
    <div class="paragraph">
      <p>Adding messages to JUnit, FEST and AssertJ assertions is an investment in your future productivity. Spend a few seconds writing them now, and you’ll save a lot of time on the other end when either the tests fail and you need to quickly diagnose the problem, or when you need to maintain the tests and the assertion messages work as a sort of documentation.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      assertEquals(4, list.size());  // Noncompliant

      try {
      fail();  // Noncompliant
      } catch (Exception e) {
      assertThat(list.get(0)).isEqualTo("pear");  // Noncompliant
      }
      ```

      ```java Fix theme={null}
      assertEquals("There should have been 4 Fruits in the list", 4, list.size());

      try {
      fail("And exception is expected here");
      } catch (Exception e) {
      assertThat(list.get(0)).as("check first element").overridingErrorMessage("The first element should be a pear, not a %s", list.get(0)).isEqualTo("pear"); 
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="@Imports should be preferred to @ComponentScans">
    <div class="paragraph">
      <p>\`@ComponentScan is used to find which Spring @Component beans (@Service or @Repository or Controller) are available in the classpath so they can be used in the application context. This is a convenient feature especially when you begin a new project but it comes with the drawback of slowing down the application start-up time especially when the application becomes bigger (ie: it references a large JAR file, or it references a significant number of JAR files, or the base-package refers to a large amount of .class files).</p>
    </div>

    <div class="paragraph">
      <p>@ComponentScan should be replaced by an explicit list of Spring beans loaded by @Import.</p>
    </div>

    <div class="paragraph">
      <p>The interface @SpringBootApplication is also considered by this rule because it is annotated with @ComponentScan\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @ComponentScan
      public class MyApplication {
      ...
      }

      @SpringBootApplication
      public class MyApplication {
      ...
      }
      ```

      ```java Fix theme={null}
      @Configuration
      @Import({
          DispatcherServletAutoConfiguration.class,
          ErrorMvcAutoConfiguration.class,
          HttpEncodingAutoConfiguration.class,
          HttpMessageConvertersAutoConfiguration.class,
          MultipartAutoConfiguration.class,
          ServerPropertiesAutoConfiguration.class,
          PropertyPlaceholderAutoConfiguration.class,
          WebMvcAutoConfiguration.class
      })
      public class MyApplication {
      ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Non-static initializer blocks should not be used for static members">
    <div class="paragraph">
      <p>When you need to perform a complicated initialization of a <code>static member, it should be done in a static initializer block. That’s because such blocks are only executed when the class is loaded into the JVM. That is, they run only once, and that happens before any instances are created. Non-static blocks, on the other hand, run once for each instance that’s created, so any static</code> members "initialized" in such a block will be re-set for each new instance.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class MyClass {
      private static List<String> names = new ArrayList<>();

      {
      names.add("foo");  // Noncompliant
      }
      ```

      ```java Fix theme={null}
      public class MyClass {
      private static List<String> names = new ArrayList<>();

      static {
      names.add("foo");
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="String multiline concatenation should be replaced with Text Blocks">
    <div class="paragraph">
      <p>In Java 15 Text Blocks are now official and can be used. The most common pattern for multiline strings in Java \< 15 was to write String concatenation. Now it’s possible to do it in a more natural way using Text Blocks.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      String textBlock =
                 "<html>\n" +
                 "    <body>\n" +
                 "        <tag>\n" +
                 "        </tag>\n" +
                 "    </body>\n" +
                 "</html>";
      ```

      ```java Fix theme={null}
      String textBlock = """
          <html>
              <body>
                  <tag>
                  </tag>
              </body>
          </html>""";
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Exception testing via JUnit ExpectedException rule should not be mixed with other assertions">
    <div class="paragraph">
      <p>When testing exception via <code>org.junit.rules.ExpectedException</code> any code after the raised exception will not be executed, so adding subsequent assertions is wrong and misleading. This rule raises an issue when an assertion is done after the "expect(…​)" invocation, only the code throwing the expected exception should be after "expect(…​)".</p>
    </div>

    <div class="paragraph">
      <p>You should consider using <a href="https://github.com/junit-team/junit4/wiki/Exception-testing#using-assertthrows-method">org.junit.Assert.assertThrows</a> instead, it’s available since JUnit 4.13 and it allows additional subsequent assertions.</p>
    </div>

    <div class="paragraph">
      <p>Alternatively, you could use <a href="https://github.com/junit-team/junit4/wiki/Exception-testing#trycatch-idiom">try-catch idiom</a> for JUnit version \< 4.13 or if your project does not support lambdas.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @Rule
      public ExpectedException thrown = ExpectedException.none();

      @Test
      public void test() throws IndexOutOfBoundsException {
      thrown.expect(IndexOutOfBoundsException.class); // Noncompliant
      Object o = get();
      // This test pass since execution will never get past this line.
      Assert.assertEquals(0, 1);
      }

      private Object get() {
      throw new IndexOutOfBoundsException();
      }
      ```

      ```java Fix theme={null}
      Assert.assertThrows(IndexOutOfBoundsException.class, () -> get());
      // This test correctly fails.
      Assert.assertEquals(0, 1);
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Optional REST parameters should have an object type">
    <div class="paragraph">
      <p>Spring provides two options to mark a REST parameter as optional:</p>
    </div>

    <div class="olist arabic">
      <ol class="arabic">
        <li>
          <p>Use required = false in the @PathVariable or @RequestParam annotation of the respective method parameter or</p>
        </li>

        <li>
          <p>Use type java.util.Optional\<T> for the method parameter</p>
        </li>
      </ol>
    </div>

    <div class="paragraph">
      <p>When using 1., the absence of the parameter, when the REST function is called, is encoded by null, which can only be used for object types.
      If required = false is used for a parameter with a primitive and the REST function is called without the parameter, a runtime exception occurs because the Spring data mapper cannot map the null value to the parameter.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      @RequestMapping(value = {"/article", "/article/{id}"})
      public Article getArticle(@PathVariable(required = false) int articleId) { // Noncompliant, null cannot be mapped to int
      //...
      }
      ```

      ```java Fix theme={null}
      @RequestMapping(value = {"/article", "/article/{id}"})
      public Article getArticle(@PathVariable(required = false) Integer articleId) { // Compliant
      //...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Assertion methods should not be used within the try block of a try-catch catching an Error">
    <div class="paragraph">
      <p>Assertion methods are throwing a "`java.lang.AssertionError`". If this call is done within the try block of a try-catch cathing a similar error, you should make sure to test some properties of the exception. Otherwise, the assertion will never fail.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @Test
      public void should_throw_assertion_error() {
      try {
      throwAssertionError();
      Assert.fail("Expected an AssertionError!"); // Noncompliant, the AssertionError will be caught and the test will never fail.
      } catch (AssertionError e) {}
      }

      private void throwAssertionError() {
      throw new AssertionError("My assertion error");
      }
      ```

      ```java Fix theme={null}
      assertThrows(AssertionError.class, () -> throwAssertionError());
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Credentials Provider should be set explicitly when creating a new AwsClient">
    <div class="paragraph">
      <p>If the credentials provider is not specified when creating a new AwsClient with an <a href="https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/awscore/client/builder/AwsClientBuilder.html">AwsClientBuilder</a>, the AWS SDK will execute some logic to identify it automatically.</p>
    </div>

    <div class="paragraph">
      <p>While it will probably identify the correct one, this extra logic will slow down startup time, already known to be a hotspot.</p>
    </div>

    <div class="paragraph">
      <p>You should therefore always define the logic to set the credentials provider yourself. This is typically done by retrieving it from the Lambda provided environment variable.</p>
    </div>

    <div class="paragraph">
      <p>This will make the code more explicit and spare initialization time.</p>
    </div>

    <div class="paragraph">
      <p>This rule reports an issue when the credentials provider is not set when creating an AwsClient.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      S3Client.builder()
      .region(Region.of(System.getenv(SdkSystemSetting.AWS_REGION.environmentVariable())))
      .build();
      ```

      ```java Fix theme={null}
      S3Client.builder()
      .region(Region.of(System.getenv(SdkSystemSetting.AWS_REGION.environmentVariable()))
      .credentialsProvider(EnvironmentVariableCredentialsProvider.create())
      .build();
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="High frame rates should not be used">
    <div class="paragraph">
      <p>Standard applications don’t require a display refresh rate above 60Hz, hence it is advisable to avoid higher frequencies to avoid unnecessary energy consumption.</p>
    </div>

    <div class="paragraph">
      <p>The rule flags an issue when setFrameRate() is invoked with a frameRate higher than 60Hz for android.view\.Surface and android.view\.SurfaceControl.Transaction.</p>
    </div>

    <div class="paragraph">
      <p>It’s important to note that the scheduler considers several factors when determining the display refresh rate. Therefore, using setFrameRate() doesn’t guarantee your app will achieve the requested frame rate.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class MainActivity extends AppCompatActivity {

      @Override
      protected void onCreate(Bundle savedInstanceState) {
          super.onCreate(savedInstanceState);
          setContentView(R.layout.activity_main);

          SurfaceView surfaceView = findViewById(R.id.my_surface_view);
          Surface surface = surfaceView.getHolder().getSurface();

          surface.setFrameRate(90.0f, Surface.FRAME_RATE_COMPATIBILITY_FIXED_SOURCE); // Noncompliant
      }
      }
      ```

      ```java Fix theme={null}
      public class MainActivity extends AppCompatActivity {

      @Override
      protected void onCreate(Bundle savedInstanceState) {
          super.onCreate(savedInstanceState);
          setContentView(R.layout.activity_main);

          SurfaceView surfaceView = findViewById(R.id.my_surface_view);
          Surface surface = surfaceView.getHolder().getSurface();

          surface.setFrameRate(60.0f, Surface.FRAME_RATE_COMPATIBILITY_FIXED_SOURCE); // Compliant
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="@Id colum setters should be private">
    <div class="paragraph">
      <p>Once set, the value of a Hibernate <code>@Entity's @Id field/column should never be updated. Therefore, setters for such fields should always be private</code>.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class Book {

      @Id
      @GeneratedValue
      private int id;

      public void setId(int id) {  // Noncompliant
      this.id = id;
      }
      ```

      ```java Fix theme={null}
      public class Book {

      @Id
      @GeneratedValue
      private int id;

      private void setId(int id) {
      this.id = id;
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="HttpServletRequest.getRequestedSessionId() should not be used">
    <div class="paragraph">
      <p>According to the API documentation of the HttpServletRequest.getRequestedSessionId() method:</p>
    </div>

    <div class="quoteblock">
      <blockquote>
        <div class="paragraph">
          <p>Returns the session ID specified by the client. This may not be the same as the ID of the current valid session for this request. If the client did not specify a session ID, this method returns null.</p>
        </div>
      </blockquote>
    </div>

    <div class="paragraph">
      <p>The session ID it returns is either transmitted through a cookie or a URL parameter. This allows an end user to manually update the value of this session ID in an HTTP request.</p>
    </div>

    <div class="paragraph">
      <p>Due to the ability of the end-user to manually change the value, the session ID in the request should only be used by a servlet container (e.g. Tomcat or Jetty) to see if the value matches the ID of an existing session.
      If it does not, the user should be considered unauthenticated.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      if (isActiveSession(request.getRequestedSessionId())) { // Noncompliant
      // ...
      }
      ```

      ```java Fix theme={null}
      if (isActiveSession(request.getSession().getId())) {
      // ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="RESOURCE_LOCAL transaction type should not be used">
    <div class="paragraph">
      <p>The use of a "RESOURCE\_LOCAL" <code>persistence-unit</code> makes you responsible for your own entity management, which involves a lot of extra boilerplate code to get right. Instead, set this to "JPA" in a JavaSE environment or omit it altogether in a JavaEE environment, where "JPA" is the default.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      <persistence-unit transaction-type="RESOURCE_LOCAL">  <!-- Noncompliant -->
      ```

      ```java Fix theme={null}
      <persistence-unit transaction-type="JTA">
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Constant parameters in a PreparedStatement should not be set more than once">
    <div class="paragraph">
      <p>The PreparedStatement is frequently used in loops because it allows to conveniently set parameters.
      A small optimization is possible by setting constant parameters outside the loop or hard-coding them in the query whenever possible.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class DatabaseExample {

      public record Order(String id, BigDecimal price) {}

      public void updateTodayOrders(Connection connection, List<Order> orders) {
              Date today = java.sql.Date.valueOf(LocalDate.now());
              String insertQuery = "INSERT INTO Order (id, price, executionDate) VALUES (?, ?, ?)";
              PreparedStatement preparedStatement = connection.prepareStatement(SQL_INSERT);

              for(Order order: orders) {
                  preparedStatement.setString(1, order.id());
                  preparedStatement.setString(2, order.price());
                  preparedStatement.setDate(3, today); // Noncompliant
                  preparedStatement.executeUpdate();
              }
      }
      }
      ```

      ```java Fix theme={null}
      public class DatabaseExample {

      public record Order(String id, BigDecimal price) {}

      public void updateTodayOrders(Connection connection, List<Order> orders) {
              Date today = java.sql.Date.valueOf(LocalDate.now());
              String insertQuery = "INSERT INTO Order (id, price, executionDate) VALUES (?, ?, ?)";
              preparedStatement.setDate(3, today); // Compliant

              PreparedStatement preparedStatement = connection.prepareStatement(SQL_INSERT);

              for(Order order: orders) {
                  preparedStatement.setString(1, order.id());
                  preparedStatement.setString(2, order.price());
                  preparedStatement.executeUpdate();
              }
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="String operations with predictable outcomes should be avoided">
    <div class="paragraph">
      <p>Operations performed on a string with predictable outcomes should be avoided. For example:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>checking if a string contains itself</p>
        </li>

        <li>
          <p>comparing a string with itself</p>
        </li>

        <li>
          <p>matching a string against itself</p>
        </li>

        <li>
          <p>creating a substring from 0 to the end of the string</p>
        </li>

        <li>
          <p>creating a substring from the end of the string</p>
        </li>

        <li>
          <p>replacing a string with itself</p>
        </li>

        <li>
          <p>replacing a substring with the exact substring</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      String speech = "SonarQube is the best static code analysis tool."

      String s1 = speech.substring(0); // Noncompliant - yields the whole string
      String s2 = speech.substring(speech.length()); // Noncompliant - yields "";
      String s3 = speech.substring(5, speech.length()); // Noncompliant - use the 1-arg version instead

      if (speech.contains(speech)) { // Noncompliant - always true
      // ...
      }
      ```

      ```java Fix theme={null}
      String speech = "SonarQube is the best static code analysis tool."

      String s1 = speech;
      String s2 = "";
      String s3 = speech.substring(5);

      // ...
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="HTTP referers should not be relied on">
    <div class="paragraph">
      <p>The fields in an HTTP request are putty in the hands of an attacker, and you cannot rely on them to tell you the truth about anything. While it may be safe to store such values after they have been neutralized, decisions should never be made based on their contents.</p>
    </div>

    <div class="paragraph">
      <p>This rule flags uses of the referer header field.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class MyServlet extends HttpServlet {
      protected void doPost(HttpServletRequest request, HttpServletResponse response) 
          throws ServletException, IOException {
      String referer = request.getHeader("referer");  // Noncompliant
      if(isTrustedReferer(referer)){
        //..
      }
      //...
      }
      }
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Files.newInputStream or Files.newOutputStream should be used">
    <div class="paragraph">
      <p>In java 7 to 9, <code>FileInputStream and FileOutputStream rely on finalization to perform final closes if the stream is not already closed. Whether or not the stream is already closed, the finalizer will be called, resulting in extra work for the garbage collector. This can easily be avoided using the Files</code> API.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      try(FileInputStream fis = new FileInputStream(...)) {  // Noncompliant
      } finally {
      }
      ```

      ```java Fix theme={null}
      try(InputStream is = Files.newInputStream(...)) {
      } finally {
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Class names should not shadow interfaces or superclasses">
    <div class="paragraph">
      <p>Two classes can have the same simple name if they are in two different packages.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      package org.foo.domain;

      public class User {
      // ..
      }
      ```

      ```java Fix theme={null}
      package org.foo.presentation;

      public class User {
      // ..
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="compareTo should not return Integer.MIN_VALUE">
    <div class="paragraph">
      <p>The Comparable.compareTo method returns a negative integer, zero, or a positive integer to indicate whether the object is less than, equal to, or greater than the parameter.
      The sign of the return value or whether it is zero is what matters, not its magnitude.</p>
    </div>

    <div class="paragraph">
      <p>Returning a positive or negative constant value other than the basic ones (-1, 0, or 1) provides no additional information to the caller.
      Moreover, it could potentially confuse code readers who are trying to understand its purpose.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      public int compareTo(Name name) {
      if (condition) {
      return Integer.MIN_VALUE; // Noncompliant
      }
      }
      ```

      ```java Fix theme={null}
      public int compareTo(Name name) {
      if (condition) {
      return -1; // Compliant
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="public static fields should be constant">
    <div class="paragraph">
      <p>There is no good reason to declare a field "public" and "static" without also declaring it "final". Most of the time this is a kludge to share a state among several objects. But with this approach, any object can do whatever it wants with the shared state, such as setting it to <code>null</code>.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class Greeter {
      public static Foo foo = new Foo();
      ...
      }
      ```

      ```java Fix theme={null}
      public class Greeter {
      public static final Foo FOO = new Foo();
      ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Exception types should not be tested using instanceof in catch blocks">
    <div class="paragraph">
      <p>A try-catch block is used to handle exceptions or errors that may occur during the execution of a block of code. It allows you to catch
      and handle exceptions gracefully, preventing your program from terminating abruptly.</p>
    </div>

    <div class="paragraph">
      <p>The code that may throw an exception is enclosed within the try block, while each catch block specifies the type of exception it can
      handle. The corresponding catch block is executed if the exception matches the type specified in any catch block. It is
      unnecessary to manually check the types using instanceof because Java automatically matches the exception type to the appropriate catch
      block based on the declared exception type in the catch clauses.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      try {
      /* ... */
      } catch (Exception e) {
      if(e instanceof IOException) { /* ... */ }         // Noncompliant
      if(e instanceof NullPointerException{ /* ... */ }  // Noncompliant
      }
      ```

      ```java Fix theme={null}
      try {
      /* ... */
      } catch (IOException e) { /* ... */ }                // Compliant
      } catch (NullPointerException e) { /* ... */ }       // Compliant
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Annotation arguments should appear in the order in which they were declared">
    <div class="paragraph">
      <p>For optimal code readability, annotation arguments should be specified in the same order that they were declared in the annotation definition.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @interface Pet {
      String name();
      String surname(); 
      }

      @Pet(surname ="", name="") // Noncompliant
      ```

      ```java Fix theme={null}
      @interface Pet {
      String name();
      String surname(); 
      }

      @Pet(name ="", surname="") // Compliant
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Assertions comparing incompatible types should not be made">
    <div class="paragraph">
      <p>Assertions comparing incompatible types always fail, and negative assertions always pass. At best, negative assertions are useless. At worst, the developer loses time trying to fix his code logic before noticing wrong assertions.</p>
    </div>

    <div class="paragraph">
      <p>Dissimilar types are:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>comparing a primitive with null</p>
        </li>

        <li>
          <p>comparing an object with an unrelated primitive (E.G. a string with an int)</p>
        </li>

        <li>
          <p>comparing unrelated classes</p>
        </li>

        <li>
          <p>comparing an array to a non-array</p>
        </li>

        <li>
          <p>comparing two arrays of dissimilar types</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>This rule also raises issues for unrelated <code>class and interface or unrelated interface</code> types in negative assertions. Because except in some corner cases, those types are more likely to be dissimilar. And inside a negative assertion, there is no test failure to inform the developer about this unusual comparison.</p>
    </div>

    <div class="paragraph">
      <p>Supported test frameworks:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>JUnit4</p>
        </li>

        <li>
          <p>JUnit5</p>
        </li>

        <li>
          <p>AssertJ</p>
        </li>
      </ul>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      interface KitchenTool {}
      interface Plant {}
      class Spatula implements KitchenTool {}
      class Tree implements Plant {}

      void assertValues(int size,
                    Spatula spatula, KitchenTool tool,  KitchenTool[] tools,
                    Tree    tree,    Plant       plant, Tree[]        trees) {

      // Whatever the given values, those negative assertions will always pass due to dissimilar types:
      assertThat(size).isNotNull();           // Noncompliant; primitives can not be null
      assertThat(spatula).isNotEqualTo(tree); // Noncompliant; unrelated classes
      assertThat(tool).isNotSameAs(tools);    // Noncompliant; array & non-array
      assertThat(trees).isNotEqualTo(tools);  // Noncompliant; incompatible arrays

      // Those assertions will always fail
      assertThat(size).isNull();                       // Noncompliant
      assertThat(spatula).isEqualTo(tree);             // Noncompliant

      // Those negative assertions are more likely to always pass
      assertThat(spatula).isNotEqualTo(plant); // Noncompliant; unrelated class and interface
      assertThat(tool).isNotEqualTo(plant);    // Noncompliant; unrelated interfaces
      }
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Use Fused Location to optimize battery power">
    <div class="paragraph">
      <p>The location awareness feature can significantly drain the device’s battery.</p>
    </div>

    <div class="paragraph">
      <p>The recommended way to maximize the battery life is to use the <em>fused location provider</em>
      which combines signals from GPS, Wi-Fi, and cell networks, as well as accelerometer, gyroscope, magnetometer and other sensors.
      The FusedLocationProviderClient automatically chooses the best method to retrieve a device’s location based on the device’s context.</p>
    </div>

    <div class="paragraph">
      <p>The rule flags an issue when android.location.LocationManager or com.google.android.gms.location.LocationClient
      is used instead of com.google.android.gms.location.FusedLocationProviderClient.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class LocationsActivity extends Activity {

      @Override
      protected void onCreate(Bundle savedInstanceState) {
          // ...

          LocationManager locationManager = (LocationManager) this.getSystemService(Context.LOCATION_SERVICE); // Noncompliant

          LocationListener locationListener = new LocationListener() {
              public void onLocationChanged(Location location) {
                  // Use the location object as needed
              }
          };

          locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0, 0, locationListener);
      }
      }
      ```

      ```java Fix theme={null}
      public class LocationsActivity extends Activity {

      @Override
      protected void onCreate(Bundle savedInstanceState) {
          // ...

          FusedLocationProviderClient fusedLocationClient = LocationServices.getFusedLocationProviderClient(this); // Compliant

          fusedLocationClient.getLastLocation()
              .addOnSuccessListener(this, location -> {
                  // Use the location object as needed
              });
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Primitive wrappers should not be instantiated only for toString or compareTo calls">
    <div class="paragraph">
      <p>Creating temporary primitive wrapper objects only for String conversion or the use of the compareTo() method is inefficient.</p>
    </div>

    <div class="paragraph">
      <p>Instead, the static toString() or compare() method of the primitive wrapper class should be used.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      private int isZero(int value){
      return Integer.valueOf(value).compareTo(0); // Noncompliant
      }
      private String convert(int value){
      return Integer.valueOf(value).toString(); // Noncompliant
      }
      ```

      ```java Fix theme={null}
      private int isZero(int value){
      return Integer.compare(value, 0); // Compliant
      }
      private String convert(int value){
      return Integer.toString(value); // Compliant
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Classes should not access their own subclasses during class initialization">
    <div class="paragraph">
      <p>Referencing a static member of a subclass from its parent during class initialization, makes the code more fragile and prone to future bugs.
      The execution of the program will rely heavily on the order of initialization of classes and their static members.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      class Parent {
      static int field1 = Child.method(); // Noncompliant
      static int field2 = 42;

      public static void main(String[] args) {
      System.out.println(Parent.field1); // will display "0" instead of "42"
      }
      }

      class Child extends Parent {
      static int method() {
      return Parent.field2;
      }
      }
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="String function use should be optimized for single characters">
    <div class="paragraph">
      <p>An <code>indexOf or lastIndexOf call with a single letter String can be made more performant by switching to a call with a char</code> argument.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      String myStr = "Hello World";
      // ...
      int pos = myStr.indexOf("W");  // Noncompliant
      // ...
      int otherPos = myStr.lastIndexOf("r"); // Noncompliant
      // ...
      ```

      ```java Fix theme={null}
      String myStr = "Hello World";
      // ...
      int pos = myStr.indexOf('W'); 
      // ...
      int otherPos = myStr.lastIndexOf('r');
      // ...
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Track uses of NOPMD suppression comments ">
    <div class="paragraph">
      <p>This rule allows you to track the use of the PMD suppression comment mechanism.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      // NOPMD
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using long-term access keys is security-sensitive">
    <div class="paragraph">
      <p>s keys will be valid until you manually revoke them. This makes them highly sensitive as any exposure can have serious consequences and should be used with care.</p>
    </div>

    <div class="paragraph">
      <p>This rule will trigger when encountering an instantiation of com.amazonaws.auth.BasicAWSCredentials.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      BasicSessionCredentials sessionCredentials = new BasicSessionCredentials(
      session_creds.getAccessKeyId(),
      session_creds.getSecretAccessKey(),
      session_creds.getSessionToken());
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Primitive types should be used for non-null values">
    <div class="paragraph">
      <p>Using boxed type suggests that <code>null</code> is a possible value for the variable. Use of the primitive type should be preferred if this is not the case to avoid any confusion about possible values variable can contain.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Integer x = 5;
      ```

      ```java Fix theme={null}
      int x = 5;
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="String.valueOf() should not be appended to a String">
    <div class="paragraph">
      <p>Appending String.valueOf() to a String decreases the code readability.</p>
    </div>

    <div class="paragraph">
      <p>The argument passed to String.valueOf() should be directly appended instead.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      String message = "Output is " + String.valueOf(12);
      ```

      ```java Fix theme={null}
      String message = "Output is " + 12;
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Future keywords should not be used as names">
    <div class="paragraph">
      <p>Programming languages evolve over time, and new versions of Java introduce additional keywords.
      If future keywords are used in the current code, it can create compatibility issues when transitioning to newer versions of Java.
      The code may fail to compile or behave unexpectedly due to conflicts with newly introduced keywords.</p>
    </div>

    <div class="paragraph">
      <p>The following keywords are marked as invalid identifiers:</p>
    </div>

    <table class="tableblock frame-all grid-all stretch">
      <thead>
        <tr>
          <th class="tableblock halign-center valign-top">Keyword</th>
          <th class="tableblock halign-center valign-top">Added in version</th>
        </tr>
      </thead>

      <tbody>
        <tr>
          <td class="tableblock halign-center valign-top"><p class="tableblock">\_</p></td>
          <td class="tableblock halign-center valign-top"><p class="tableblock">9</p></td>
        </tr>

        <tr>
          <td class="tableblock halign-center valign-top"><p class="tableblock">enum</p></td>
          <td class="tableblock halign-center valign-top"><p class="tableblock">5.0</p></td>
        </tr>
      </tbody>
    </table>

    <div class="paragraph">
      <p>assert and strictfp are another example of valid identifiers which became keywords in later versions, but are not supported by this rule.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      public class MyClass {
      int enum = 42;            // Noncompliant
      String _ = "";            // Noncompliant
      }
      ```

      ```java Fix theme={null}
      public class MyClass {
      int magic = 42;           // Noncompliant
      String s = "";            // Noncompliant
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Unnecessary boxing and unboxing should be avoided">
    <div class="paragraph">
      <p>Boxing is the process of putting a primitive value into a wrapper object, such as creating an Integer to hold an int value.
      Unboxing is the process of retrieving the primitive value from such an object.
      Since the original value is unchanged during boxing and unboxing, there is no point in doing either when not needed.</p>
    </div>

    <div class="paragraph">
      <p>Instead, you should rely on Java’s implicit boxing/unboxing to convert from the primitive type to the wrapper type and vice versa, for better readability.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public void examinePrimitiveInt(int a) {
      //... 
      }

      public void examineBoxedInteger(Integer a) {
      // ...
      }

      public void func() {
      int primitiveInt = 0;
      Integer boxedInt = Integer.valueOf(0);
      double d = 1.0;

      int dIntValue = Double.valueOf(d).intValue(); // Noncompliant; should be replaced with a simple cast

      examinePrimitiveInt(boxedInt.intValue()); // Noncompliant; unnecessary unboxing
      examinePrimitiveInt(Integer.valueOf(primitiveInt));  // Noncompliant; boxed int will be auto-unboxed

      examineBoxedInteger(Integer.valueOf(primitiveInt)); // Noncompliant; unnecessary boxing
      examineBoxedInteger(boxedInt.intValue()); // Noncompliant; unboxed int will be autoboxed
      }
      ```

      ```java Fix theme={null}
      public void examinePrimitiveInt(int a) {
      //... 
      }

      public void examineBoxedInteger(Integer a) {
      // ...
      }

      public void func() {
      int primitiveInt = 0;
      Integer boxedInt = Integer.valueOf(0);
      double d = 1.0;

      int dIntValue = (int) d;

      examinePrimitiveInt(primitiveInt);
      examinePrimitiveInt(boxedInt);

      examineBoxedInteger(primitiveInt);
      examineBoxedInteger(boxedInt);
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Functions should not be defined with a variable number of arguments">
    <div class="paragraph">
      <p>As stated per effective java :</p>
    </div>

    <div class="quoteblock">
      <blockquote>
        <div class="paragraph">
          <p>Varargs methods are a convenient way to define methods that require a variable number of arguments, but they should not be overused. They can produce confusing results if used inappropriately.</p>
        </div>
      </blockquote>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      void fun ( String... strings )	// Noncompliant
      {
      // ...
      }
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="equals(Object obj) and hashCode() should be overridden in pairs">
    <div class="paragraph">
      <p>According to the Java Language Specification, there is a contract between \`equals(Object) and hashCode():</p>
    </div>

    <div class="quoteblock">
      <blockquote>
        <div class="paragraph">
          <p>If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.</p>
        </div>

        <div class="paragraph">
          <p>It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode\` method on each of the two objects must produce distinct integer results.</p>
        </div>

        <div class="paragraph">
          <p>However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables.</p>
        </div>
      </blockquote>
    </div>

    <div class="paragraph">
      <p>In order to comply with this contract, those methods should be either both inherited, or both overridden.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      class MyClass {    // Noncompliant - should also override "hashCode()"

      @Override
      public boolean equals(Object obj) {
      /* ... */
      }

      }
      ```

      ```java Fix theme={null}
      class MyClass {    // Compliant

      @Override
      public boolean equals(Object obj) {
      /* ... */
      }

      @Override
      public int hashCode() {
      /* ... */
      }

      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Parent class default constructors should not be called">
    <div class="paragraph">
      <p>Each constructor must first invoke a parent class constructor, but it doesn’t always have to be done explicitly. If the parent class has a reachable, no-args constructor, a call to it will be inserted automatically by the compiler. Thus, calls to <code>super()</code> can be omitted.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class MyClass {
      private Foo foo;

      public MyClass (Foo foo) {
      super(); // Noncompliant
      this.foo = foo;
      }
      ```

      ```java Fix theme={null}
      public class MyClass {
      private Foo foo;

      public MyClass (Foo foo) {
      this.foo = foo;
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Methods setUp() and tearDown() should be correctly annotated starting with JUnit4">
    <div class="paragraph">
      <p>The \`setUp() and tearDown() methods (initially introduced with JUnit3 to execute a block of code before and after each test) need to be correctly annotated with the equivalent annotation in order to preserve the same behavior when migrating from JUnit3 to JUnit4 or JUnit5.</p>
    </div>

    <div class="paragraph">
      <p>This rule consequently raise issues on setUp() and tearDown()\` methods which are not annotated in test classes.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public void setUp() { ... } // Noncompliant; should be annotated with @Before
      public void tearDown() { ... }  // Noncompliant; should be annotated with @After
      ```

      ```java Fix theme={null}
      public void setUp() { ... } // Noncompliant; should be annotated with @BeforeEach
      public void tearDown() { ... }  // Noncompliant; should be annotated with @AfterEach
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="@Service classes should not have communication-related members">
    <div class="paragraph">
      <p>A cleanly coded web application will have a  clear separation of concerns, with business logic in the \`@Service layer, and communication with other systems in the data access layer.</p>
    </div>

    <div class="paragraph">
      <p>To help enforce such a separation of concerns, this rule raises an issue when a @Service class has RestTemplate, JmsTemplate, WebServiceTemplate, JdbcTemplate, or DataSource\` member.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @Service ("greetingmanager")
      public class GreetingManagerImpl implements GreetingManager
      {
      @Autowired
      DataSource ds;  // Noncompliant
      ```

      ```java Fix theme={null}
      @Service ("greetingmanager")
      public class GreetingManagerImpl implements GreetingManager
      {
      @Autowired
      GreetingDao gdao;  // DataSource and its use have been moved here
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="URL.hashCode and URL.equals should be avoided">
    <div class="paragraph">
      <p>The equals and hashCode methods of java.net.URL may trigger a name service lookup (typically DNS) to resolve the hostname or IP
      address. Depending on the configuration, and network status, this lookup can be time-consuming.</p>
    </div>

    <div class="paragraph">
      <p>On the other hand, the URI class does not perform such lookups and is a better choice unless you specifically require the functionality
      provided by URL.</p>
    </div>

    <div class="paragraph">
      <p>In general, it is better to use the URI class until access to the resource is actually needed, at which point you can convert the URI to
      a URL using URI.toURL().</p>
    </div>

    <div class="paragraph">
      <p>This rule checks for uses of URL 's in Map and Set , and for explicit calls to the equals and hashCode methods.
      It suggests reconsidering the use of URL in such scenarios to avoid potential performance issues related to name service lookups.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      public void checkUrl(URL url) {
      Set<URL> sites = new HashSet<URL>();               // Noncompliant

      URL homepage = new URL("http://sonarsource.com");  // Compliant
      if (homepage.equals(url)) {                        // Noncompliant
      // ...
      }
      }
      ```

      ```java Fix theme={null}
      public void checkUrl(URL url) {
      Set<URI> sites = new HashSet<URI>();               // Compliant

      URI homepage = new URI("http://sonarsource.com");  // Compliant
      URI uri = url.toURI();
      if (homepage.equals(uri)) {                        // Compliant
      // ...
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Strings literals should be placed on the left side when checking for equality">
    <div class="paragraph">
      <p>It is preferable to place string literals on the left-hand side of an <code>equals() or equalsIgnoreCase()</code> method call.</p>
    </div>

    <div class="paragraph">
      <p>This prevents null pointer exceptions from being raised, as a string literal can never be null by definition.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      String myString = null;

      System.out.println("Equal? " + myString.equals("foo"));                        // Noncompliant; will raise a NPE
      System.out.println("Equal? " + (myString != null && myString.equals("foo")));  // Noncompliant; null check could be removed
      ```

      ```java Fix theme={null}
      System.out.println("Equal?" + "foo".equals(myString));                         // properly deals with the null case
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Loggers should be named for their enclosing classes">
    <div class="paragraph">
      <p>It is convention to name each class’s logger for the class itself. Doing so allows you to set up clear, communicative logger configuration. Naming loggers by some other convention confuses configuration, and using the same class name for multiple class loggers prevents the granular configuration of each class' logger. Some libraries, such as SLF4J warn about this, but not all do.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when a logger is not named for its enclosing class.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class MyClass {
      private final static Logger LOG = LoggerFactory.getLogger(WrongClass.class);  // Noncompliant; multiple classes using same logger
      }
      ```

      ```java Fix theme={null}
      public class MyClass {
      private final static Logger LOG = LoggerFactory.getLogger(MyClass.class);
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="InterruptedException and ThreadDeath should not be ignored">
    <div class="paragraph">
      <p>If an InterruptedException or a ThreadDeath error is not handled properly, the information that the thread was interrupted will be lost.
      Handling this exception means either to re-throw it or manually re-interrupt the current thread by calling Thread.interrupt().
      Simply logging the exception is not sufficient and counts as ignoring it.
      Between the moment the exception is caught and handled, is the right time to perform cleanup operations on the method’s state, if needed.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public void run () {
      try {
      /*...*/
      } catch (InterruptedException e) { // Noncompliant; logging is not enough
      LOGGER.log(Level.WARN, "Interrupted!", e);
      }
      }
      ```

      ```java Fix theme={null}
      public void run () {
      try {
      /* ... */
      } catch (InterruptedException e) { // Compliant; the interrupted state is restored
      LOGGER.log(Level.WARN, "Interrupted!", e);
      /* Clean up whatever needs to be handled before interrupting  */
      Thread.currentThread().interrupt();
      }
      }

      public void run () {
      try {
      /* ... */
      } catch (ThreadDeath e) { // Compliant; the error is being re-thrown
      LOGGER.log(Level.WARN, "Interrupted!", e);
      /* Clean up whatever needs to be handled before re-throwing  */
      throw e;
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Date and time should not be used as a type for primary keys">
    <div class="paragraph">
      <p>Using a \`type="timestamp" column as the primary key of a table is slightly risky. Two threads could create new objects in the table close enough in sequence for them to both have the same timestamp. Alternately, this could happen during a daylight savings time change. Instead, use a numeric value as the @Id.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when a time or date-related class is annotated with @Id\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class Person {

      @Id
      @Type(type="timestamp")
      private Date birthDate;  // Noncompliant

      private String lastName;
      // ...
      }
      ```

      ```java Fix theme={null}
      public class Person {

      @Id
      @GeneratedValue
      int id;

      @Type(type="timestamp")
      private Date birthDate;

      private String lastName;
      // ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="GZIPInputStream should not read from BufferedInputStream">
    <div class="paragraph">
      <p>The class \`java.util.zip.GZIPInputStream is already buffering its input while reading. Thus passing a java.io.BufferedInputStream to a java.util.zip.GZIPInputStream is redundant. It is more efficient to directly pass the original input stream to java.util.zip.GZIPInputStream.</p>
    </div>

    <div class="paragraph">
      <p>Note that the default buffer size of GZIPInputStream is not the same as the one in BufferedInputStream. Configure it if need be.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when a java.util.zip.GZIPInputStream reads from a java.io.BufferedInputStream\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      import java.io.*;
      import java.util.zip.GZIPInputStream;

      public class Noncompliant {

      void deflateFile(final File file) throws IOException {
          try (
              FileInputStream fileStream = new FileInputStream(file);
              BufferedInputStream bufferedStream = new BufferedInputStream(fileStream);
              InputStream input = new GZIPInputStream(bufferedStream); // Noncompliant
          ) {
              // process the input
          }
      }
      }
      ```

      ```java Fix theme={null}
      import java.io.*;
      import java.util.zip.GZIPInputStream;
      public class Compliant {

      void deflateFile(final File file) throws IOException {
          try (
              FileInputStream fileStream = new FileInputStream(file);
              InputStream input = new GZIPInputStream(fileStream);
          ) {
              // process the input
          }
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Arrays and lists should not be copied using loops">
    <div class="paragraph">
      <p>The JDK provides a set of built-in methods to copy the contents of an array into another array.
      Using a loop to perform the same operation is less clear, more verbose and should be avoided.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public void copyArray(String[] source){
      String[] array = new String[source.length];
      for (int i = 0; i < source.length; i++) {
      array[i] = source[i]; // Noncompliant
      }
      }

      public void copyList(List<String> source) {
      List<String> list = new ArrayList<>();
      for (String s : source) {
      list.add(s); // Noncompliant
      }
      }
      ```

      ```java Fix theme={null}
      public void copyArray(String[] source){
      String[] array = Arrays.copyOf(source, source.length);
      }

      public void copyList(List<String> source) {
      List<String> list = new ArrayList<>();
      Collections.addAll(list, source);
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="ResultSet.isLast() should not be used">
    <div class="paragraph">
      <p>There are several reasons to avoid using this method:</p>
    </div>

    <div class="olist arabic">
      <ol class="arabic">
        <li>
          <p>It is optionally available only for result sets of type ResultSet.TYPE\_FORWARD\_ONLY.
          Database drivers will throw an exception if not supported.</p>
        </li>

        <li>
          <p>The method can be expensive to execute as the database driver may need to fetch ahead one row to determine whether the current row is the last in the result set.
          The documentation of the method explicitly mentions this fact.</p>
        </li>

        <li>
          <p>What "the cursor is on the last row" means for an empty ResultSet is unclear.
          Database drivers may return true or false in this case .</p>
        </li>
      </ol>
    </div>

    <div class="paragraph">
      <p>ResultSet.next() is a good alternative to ResultSet.isLast() as it does not have the mentioned issues.
      It is always supported and, as per specification, returns false for empty result sets.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      ResultSet results = stmt.executeQuery("SELECT name, address FROM PERSON");
      StringBuilder sb = new StringBuilder();
      while (results.next() && !results.isLast()) { // Noncompliant
      sb.append(results.getString("name") + ", ");
      }
      sb.append(results.getString("name"));
      String formattedNames = sb.toString();
      ```

      ```java Fix theme={null}
      ResultSet results = stmt.executeQuery("SELECT name, address FROM PERSON");
      List<String> names = new ArrayList<>();
      while (results.next()) { // Compliant, and program logic refactored
      names.add(results.getString("name"));
      }
      String formattedNames =  names.stream().collect(Collectors.joining(", "));
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Generic wildcard types should not be used in return types">
    <div class="paragraph">
      <p>A return type containing wildcards cannot be narrowed down in any context.
      This indicates that the developer’s intention was likely something else.</p>
    </div>

    <div class="paragraph">
      <p>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 <em>covariance</em>.
      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 <em>contravariance</em>.
      This can be traced back to the Liskov substitution principle.</p>
    </div>

    <div class="paragraph">
      <p>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.</p>
    </div>

    <div class="paragraph">
      <p>Wildcards can be employed to achieve covariance or contravariance in situations
      where the type parameter appears in one position only:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>\<? extends Foo> for covariance (input positions)</p>
        </li>

        <li>
          <p>\<? super Foo> for contravariance (output positions)</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>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.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      List<? extends Animal> getAnimals() { ... } // Noncompliant, wildcard with no use
      List<? super Plant> getLifeforms() { ... }  // Noncompliant, wildcard with no use
      ```

      ```java Fix theme={null}
      List<Animal> getAnimals() { ... }           // Compliant, using invariant type instead
      List<Plant> getLifeforms() { ... }          // Compliant, using invariant type instead
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Strings and Boxed types should be compared using equals()">
    <div class="paragraph">
      <p>It’s almost always a mistake to compare two instances of <code>java.lang.String or boxed types like java.lang.Integer using reference equality == or !=</code>, because it is not comparing actual value but locations in memory.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      String firstName = getFirstName(); // String overrides equals 
      String lastName = getLastName();

      if (firstName == lastName) { ... }; // Non-compliant; false even if the strings have the same value
      ```

      ```java Fix theme={null}
      String firstName = getFirstName();
      String lastName = getLastName();

      if (firstName != null && firstName.equals(lastName)) { ... };
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Only one method invocation is expected when testing checked exceptions">
    <div class="paragraph">
      <p>When verifying that code raises an exception, a good practice is to avoid having multiple method calls inside the tested code, to be explicit about what is exactly tested.</p>
    </div>

    <div class="paragraph">
      <p>When two of the methods can raise the same <strong>checked</strong> exception, not respecting this good practice is a bug, since it is not possible to know what is really tested.</p>
    </div>

    <div class="paragraph">
      <p>You should make sure that only one method can raise the expected checked exception in the tested code.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @Test
      public void testG() {
      // Do you expect g() or f() throwing the exception?
      assertThrows(IOException.class, () -> g(f(1)) ); // Noncompliant
      }

      @Test
      public void testGTryCatchIdiom() {
      try { // Noncompliant
      g(f(1)); 
      Assert.fail("Expected an IOException to be thrown");
      } catch (IOException e) {
      // Test exception message...
      }
      }

      int f(int x) throws IOException {
      // ...
      }

      int g(int x) throws IOException {
      // ...
      }
      ```

      ```java Fix theme={null}
      @Test
      public void testG() {
      int y = f(1);
      // It is explicit that we expect an exception from g() and not f()
      assertThrows(IOException.class, () -> g(y) );
      }

      @Test
      public void testGTryCatchIdiom() {
      int y = f(1);
      try {
      g(y); 
      Assert.fail("Expected an IOException to be thrown");
      } catch (IOException e) {
      // Test exception message...
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Exceptions should not be thrown in finally blocks">
    <CodeGroup>
      ```java Bad theme={null}
      try {
      /* some work which end up throwing an exception */
      throw new IllegalArgumentException();
      } finally {
      /* clean up */
      throw new RuntimeException();       // Noncompliant; masks the IllegalArgumentException
      }
      ```

      ```java Fix theme={null}
      try {
      /* some work which end up throwing an exception */
      throw new IllegalArgumentException();
      } finally {
      /* clean up */
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="entrySet() should be iterated when both the key and value are needed">
    <div class="paragraph">
      <p>Map is an object that maps keys to values. A map cannot contain duplicate keys, which means each key can map to at most one value.</p>
    </div>

    <div class="paragraph">
      <p>When both the key and the value are needed, it is more efficient to iterate the entrySet(), which will give access to both instead of
      iterating over the keySet() and then getting the value.</p>
    </div>

    <div class="paragraph">
      <p>If the entrySet() method is not iterated when both the key and value are needed, it can lead to unnecessary lookups. This is because each
      lookup requires two operations: one to retrieve the key and another to retrieve the value. By iterating the entrySet() method, the
      key-value pair can be retrieved in a single operation, which can improve performance.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public void doSomethingWithMap(Map<String,Object> map) {
      for (String key : map.keySet()) {  // Noncompliant; for each key the value is retrieved
      Object value = map.get(key);
      // ...
      }
      }
      ```

      ```java Fix theme={null}
      public void doSomethingWithMap(Map<String,Object> map) {
      for (Map.Entry<String,Object> entry : map.entrySet()) {
      String key = entry.getKey();
      Object value = entry.getValue();
      // ...
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Exact alarms should not be abused">
    <div class="paragraph">
      <p>The use of exact alarms triggers the device to wake up at precise times
      that can lead several wake-ups in a short period of time.
      The wake-up mechanism is a significant battery drain because it requires powering up the main processor
      and pulling it out of a low-power state.</p>
    </div>

    <div class="paragraph">
      <p>It’s highly recommended to create an inexact alarm whenever possible.</p>
    </div>

    <div class="paragraph">
      <p>It is also recommended for normal timing operations, such as  ticks and timeouts, using the Handler,
      and for long-running operations, such as network downloads, using WorkManager or JobScheduler.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class AlarmScheduler {
      private Context context;

      public AlarmScheduler(Context context) {
          this.context = context;
      }

      public void scheduleAlarm(long triggerTime) {
          AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
          Intent intent = new Intent(context, AlarmReceiver.class);
          PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

          alarmManager.setExact(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent); // Noncompliant, avoid using exact alarms unless necessary
          alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent); // Noncompliant, avoid using exact alarms unless necessary

          long windowLengthMillis = 5 * 60 * 1000; // 5 minutes in milliseconds
          alarmManager.setWindow(AlarmManager.RTC_WAKEUP, triggerTime, windowLengthMillis, pendingIntent); // Noncompliant, don't use windows below 10 minutes
      }
      }
      ```

      ```java Fix theme={null}
      public class AlarmScheduler {
      private Context context;

      public AlarmScheduler(Context context) {
          this.context = context;
      }

      public void scheduleAlarm(long triggerTime) {
          AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
          Intent intent = new Intent(context, AlarmReceiver.class);
          PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

          alarmManager.set(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent); // Compliant
          alarmManager.setAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent);  // Compliant

          long windowLengthMillis = 10 * 60 * 1000; // 10 minutes in milliseconds
          alarmManager.setWindow(AlarmManager.RTC_WAKEUP, triggerTime, windowLengthMillis, pendingIntent); // Compliant
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Bean Validation (JSR 380) should be properly configured">
    <div class="paragraph">
      <p>\`Bean Validation as per defined by JSR 380 can be triggered programmatically or also executed by the Bean Validation providers. However something should tell the Bean Validation provider that a variable must be validated otherwise no validation will happen. This can be achieved by annotating a variable with javax.validation.Valid and unfortunally it’s easy to forget to add this annotation on complex Beans.</p>
    </div>

    <div class="paragraph">
      <p>Not annotating a variable with @Valid means Bean Validation will not be triggered for this variable, but readers may overlook this omission and assume the variable will be validated.</p>
    </div>

    <div class="paragraph">
      <p>This rule will run by default on all Class'es and therefore can generate a lot of noise. This rule should be restricted to run only on certain layers. For this reason, the "Restrict Scope of Coding Rules" feature should be used to check for missing @Valid\` annotations only on some packages of the application.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      import javax.validation.Valid;
      import javax.validation.constraints.NotNull;

      public class User {
      @NotNull
      private String name;
      }

      public class Group {
      @NotNull
      private List<User> users; // Noncompliant; User instances are not validated
      }

      public class MyService {
      public void login(User user) { // Noncompliant; parameter "user" is not validated
      }
      }
      ```

      ```java Fix theme={null}
      import javax.validation.Valid;
      import javax.validation.constraints.NotNull;

      public class User {
      @NotNull
      private String name;
      }

      public class Group {
      @Valid
      @NotNull
      private List<User> users; // Compliant; User instances are validated

      @NotNull
      // preferred style as of Bean Validation 2.0
      private List<@Valid User> users2; // Compliant; User instances are validated
      }

      public class MyService {
      public void login(@Valid User user) { // Compliant
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Avoid using FetchType.EAGER">
    <div class="paragraph">
      <p>Using FetchType.EAGER can lead to inefficient data loading and potential performance issues.
      Eager Loading initializes associated data on the spot, potentially fetching more data than needed.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      @OneToMany(mappedBy = "parent", fetch = FetchType.EAGER) // Noncompliant
      private List<ChildEntity> children;

      @OneToMany(mappedBy = "child", fetch = FetchType.EAGER) // Noncompliant
      private List<ParentEntity> parents;
      ```

      ```java Fix theme={null}
      @OneToMany(mappedBy = "parent", fetch = FetchType.LAZY) // Compliant
      private List<ChildEntity> children;

      @OneToMany(mappedBy = "child") // Compliant
      private List<ParentEntity> parents;
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Blocks should be synchronized on private final fields">
    <div class="paragraph">
      <p>Synchronizing on a class field synchronizes not on the field itself, but on the object assigned to it. So synchronizing on a non-<code>final</code> field makes it possible for the field’s value to change while a thread is in a block synchronized on the old value. That would allow a second thread, synchronized on the new value, to enter the block at the same time.</p>
    </div>

    <div class="paragraph">
      <p>The story is very similar for synchronizing on parameters; two different threads running the method in parallel could pass two different object instances in to the method as parameters, completely undermining the synchronization.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      private String color = "red";

      private void doSomething(){
      synchronized(color) {  // Noncompliant; lock is actually on object instance "red" referred to by the color variable
      //...
      color = "green"; // other threads now allowed into this block
      // ...
      }
      synchronized(new Object()) { // Noncompliant this is a no-op.
       // ...
      }
      }
      ```

      ```java Fix theme={null}
      private String color = "red";
      private final Object lockObj = new Object();

      private void doSomething(){
      synchronized(lockObj) {
      //...
      color = "green";
      // ...
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="free should be called on blobs and clobs">
    <div class="paragraph">
      <p>According to the JDBC specification:</p>
    </div>

    <div class="quoteblock">
      <blockquote>
        <div class="paragraph">
          <p><code>Blob, Clob, and NClob</code> Java objects remain valid for at least the duration of the transaction in which they are created. This could potentially result in an application running out of resources during a long running transaction.</p>
        </div>
      </blockquote>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      PreparedStatement ps = conn.prepareStatement("SELECT text, img from photos where author=?");
      ps.setString(1,author);
      ResultSet rs = ps.executeQuery();
      while (rs.next()) {
      Image image = saveImg(rs.getBlob("img").getBinaryStream());  // Noncompliant; blob is never freed
      image.addCaption(rs.getClob("text").getCharacterStream());  // Noncompliant
      }
      ```

      ```java Fix theme={null}
      PreparedStatement ps = conn.prepareStatement("SELECT text, img from photos where author=?");
      ps.setString(1,author);
      ResultSet rs = ps.executeQuery();
      while (rs.next()) {
      Blob blob = rs.getBlob("img");
      Image image = saveImg(blob.getBinaryStream());
      blob.free();

      Clob clob = rs.getClob("text");
      image.addCaption(clob.getCharacterStream());
      clob.free();
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Cryptographic RSA algorithms should always incorporate OAEP (Optimal Asymmetric Encryption Padding)">
    <div class="paragraph">
      <p>Without OAEP in RSA encryption, it takes less work for an attacker to decrypt the data or infer patterns from the ciphertext. This rule logs an issue as soon as a literal value starts with <code>RSA/NONE</code>.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Cipher rsa = javax.crypto.Cipher.getInstance("RSA/NONE/NoPadding");
      ```

      ```java Fix theme={null}
      Cipher rsa = javax.crypto.Cipher.getInstance("RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING");
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="SequencedCollection methods should be preferred to get the first or last element">
    <div class="paragraph">
      <p>Java 21 introduces a new SequencedCollection interface that provides a uniform API for accessing its first and last elements.
      The new getFirst() and getLast() methods offer a consistent way to access elements across SortedSet, NavigableSet, LinkedHashSet, List and Deque collections.
      Because those methods are more concise and readable, they should be used instead of more complex workarounds that recreate the same behavior.</p>
    </div>

    <div class="paragraph">
      <p>For example, list.get(list.size() - 1) can be replaced by list.getLast().</p>
    </div>

    <div class="paragraph">
      <p>This rule identifies code that can be simplified by using the new getFirst() and getLast() methods.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      public String concatenateFirstAndLast(List<String> list) {
      return list.get(0) + // Noncompliant
      list.get(list.size() - 1); // Noncompliant
      }
      ```

      ```java Fix theme={null}
      public String concatenateFirstAndLast(List<String> list) {
      return list.getFirst() + // Compliant
      list.getLast(); // Compliant
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="JEE applications should not use threads or synchronization">
    <div class="paragraph">
      <p>Proper synchronization and thread management can be tricky under the best of circumstances, but it’s particularly difficult in JEE application, and is even forbidden under some circumstances by the JEE standard.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue for each <code>Runnable, and use of the synchronized</code> keyword.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
      // ...

      Runnable r = new Runnable() {  // Noncompliant 
      public void run() {
        // ...
      }
      };
      new Thread(r).start();
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="NullPointerException should not be caught">
    <div class="paragraph">
      <p><code>NullPointerException should be avoided, not caught. Any situation in which NullPointerException is explicitly caught can easily be converted to a null</code> test, and any behavior being carried out in the catch block can easily be moved to the "is null" branch of the conditional.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public int lengthPlus(String str) {
      int len = 2;
      try {
      len += str.length();
      }
      catch (NullPointerException e) {
      log.info("argument was null");
      }
      return len;
      }
      ```

      ```java Fix theme={null}
      public int lengthPlus(String str) {
      int len = 2;

      if (str != null) {
      len += str.length();
      }
      else {
      log.info("argument was null");
      }
      return len;
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Enum values should be compared with ==">
    <div class="paragraph">
      <p>Testing equality of an enum value with \`equals is perfectly valid because an enum is an Object and every Java developer knows "==" should not be used to compare the content of an Object. At the same time, using "==" on enums:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>provides the same expected comparison (content) as equals</p>
        </li>

        <li>
          <p>is more null-safe than equals()</p>
        </li>

        <li>
          <p>provides compile-time (static) checking rather than runtime checking</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>For these reasons, use of "==" should be preferred to equals\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public enum Fruit {
      APPLE, BANANA, GRAPE
      }

      public enum Cake {
      LEMON_TART, CHEESE_CAKE
      }

      public boolean isFruitGrape(Fruit candidateFruit) {
      return candidateFruit.equals(Fruit.GRAPE); // Noncompliant; this will raise an NPE if candidateFruit is NULL
      }

      public boolean isFruitGrape(Cake candidateFruit) {
      return candidateFruit.equals(Fruit.GRAPE); // Noncompliant; always returns false
      }
      ```

      ```java Fix theme={null}
      public boolean isFruitGrape(Fruit candidateFruit) {
      return candidateFruit == Fruit.GRAPE; // Compliant; there is only one instance of Fruit.GRAPE - if candidateFruit is a GRAPE it will have the same reference as Fruit.GRAPE
      }

      public boolean isFruitGrape(Cake candidateFruit) {
      return candidateFruit == Fruit.GRAPE; // Compliant; compilation time failure
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="final classes should not have protected members">
    <div class="paragraph">
      <p>The difference between \`private and protected visibility is that child classes can see and use protected members, but they cannot see private ones. Since a final class will have no children, marking the members of a final class protected is confusingly pointless.</p>
    </div>

    <div class="paragraph">
      <p>Note that the protected\` members of a class can also be seen and used by other classes that are placed within the same package, this could lead to accidental, unintended access to otherwise private members.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public final class MyFinalClass {

      protected String name = "Fred";  // Noncompliant
      protected void setName(String name) {  // Noncompliant
      // ...
      }
      ```

      ```java Fix theme={null}
      public final class MyFinalClass {

      private String name = "Fred";
      public void setName(String name) {
      // ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Types should be used in lambdas">
    <div class="paragraph">
      <p>Shared coding conventions allow teams to collaborate effectively. While types for lambda arguments are optional, specifying them anyway makes the code clearer and easier to read.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Arrays.sort(rosterAsArray,
      (a, b) -> {  // Noncompliant
          return a.getBirthday().compareTo(b.getBirthday());
      }
      );
      ```

      ```java Fix theme={null}
      Arrays.sort(rosterAsArray,
      (Person a, Person b) -> {
          return a.getBirthday().compareTo(b.getBirthday());
      }
      );
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Files opened in append mode should not be used with ObjectOutputStream">
    <div class="paragraph">
      <p>An ObjectOutputStream writes primitive data types and graphs of Java objects to an OutputStream.
      The objects can be read (reconstituted) using an ObjectInputStream.</p>
    </div>

    <div class="paragraph">
      <p>When ObjectOutputStream is used with files opened in append mode, it can cause data corruption and unexpected behavior.
      This is because when ObjectOutputStream is created, it writes metadata to the output stream, which can conflict with the existing
      metadata when the file is opened in append mode. This can lead to errors and data loss.</p>
    </div>

    <div class="paragraph">
      <p>When used with serialization, an ObjectOutputStream first writes the serialization stream header. This header should appear
      once per file at the beginning.
      When you’re trying to read your object(s) back from the file, only the first one will be read successfully, and a StreamCorruptedException
      will be thrown after that.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      FileOutputStream fos = new FileOutputStream(fileName , true);  // fos opened in append mode
      ObjectOutputStream out = new ObjectOutputStream(fos);  // Noncompliant
      ```

      ```java Fix theme={null}
      FileOutputStream fos = new FileOutputStream(fileName);
      ObjectOutputStream out = new ObjectOutputStream(fos);
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Mutable fields should not be public static">
    <div class="paragraph">
      <p>There is no good reason to have a mutable object as the \`public (by default), static member of an interface. Such variables should be moved into classes and their visibility lowered.</p>
    </div>

    <div class="paragraph">
      <p>Similarly, mutable static members of classes and enumerations which are accessed directly, rather than through getters and setters, should be protected to the degree possible. That can be done by reducing visibility or making the field final if appropriate.</p>
    </div>

    <div class="paragraph">
      <p>Note that making a mutable field, such as an array, final will keep the variable from being reassigned, but doing so has no effect on the mutability of the internal state of the array (i.e. it doesn’t accomplish the goal).</p>
    </div>

    <div class="paragraph">
      <p>This rule raises issues for public static array, Collection, Date, and awt.Point\` members.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public interface MyInterface {
      public static String [] strings; // Noncompliant
      }

      public class A {
      public static String [] strings1 = {"first","second"};  // Noncompliant
      public static String [] strings2 = {"first","second"};  // Noncompliant
      public static List<String> strings3 = new ArrayList<>();  // Noncompliant
      // ...
      }
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Database-related resources should be closed in reverse of the order they were opened">
    <div class="paragraph">
      <p>The order in which you `close database-releated resources is crucial. Close a Connection first, and depending on the database pooling in use, you may no longer be able to truly reach its Statements and ResultSet`s to close them, even though the calls are made and execute without error.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Connection conn = null;
      PreparedStatement ps = null;
      ResultSet rs = null;
      try {
      conn = DriverManager.getConnection(connectionString);
      ps = conn.prepareStatement(query);
      rs = ps.executeQuery();
      // ...
      } finally {
      try { 
      if (conn != null) {
        conn.close();   // Noncompliant; close this last
      }
      } catch (Exception e) {};
      try { 
      if (ps != null) {
        ps.close(); 
      }
      } catch (Exception e) {};
      try { 
      if (rs != null) {
        rs.close(); 
      }
      } catch (Exception e) {};
      }
      ```

      ```java Fix theme={null}
      Connection conn = null;
      PreparedStatement ps = null;
      ResultSet rs = null;
      try {
      conn = DriverManager.getConnection(connectionString);
      ps = conn.prepareStatement(query);
      rs = ps.executeQuery();
      // ...
      } finally {
      try { 
      if (rs != null) {
        rs.close(); 
      }
      } catch (Exception e) {};
      try { 
      if (ps != null) {
        ps.close(); 
      }
      } catch (Exception e) {};
      try { 
      if (conn != null) {
        conn.close(); 
      }
      } catch (Exception e) {};
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="static SWT Images should not hold file handles">
    <div class="paragraph">
      <p>When an SWT \`Image accesses a file directly, it holds the file handle for the life of the image. Do this many times, and the OS may run out of available file handles. At minimum, SWT Images which directly access files should not be static. At best, they should access their files through ImageDescriptors, which do not hold open file handles.</p>
    </div>

    <div class="paragraph">
      <p>This rule looks for org.eclipse.swt.graphics.Images which both directly access a file on the file path and are static\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      import org.eclipse.swt.graphics.Image;

      public class MyView {
      static Image myImage = new Image("path/to/file.png"); // Noncompliant
      ```

      ```java Fix theme={null}
      import org.eclipse.swt.graphics.Image;
      import org.eclipse.jface.resource.ImageDescriptor;

      public class MyView {
      static ImageDescription myDescriptor = ImageDescriptor.createFromFile("path/to/file.png");  // Doesn't hold file handle open
      Image myImage = myDescriptor.getImage();
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Allowing deserialization of LDAP objects is security-sensitive">
    <div class="paragraph">
      <p>ialization of objects from LDAP directories, which can lead to remote code execution.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when an LDAP search query is executed with <code>SearchControls</code> configured to allow deserialization.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      DirContext ctx = new InitialDirContext();
      // ...
      ctx.search(query, filter,
          new SearchControls(scope, countLimit, timeLimit, attributes,
              false, // Compliant
              deref));
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Methods should not call same-class methods with incompatible @Transactional values">
    <div class="paragraph">
      <p>Transactional methods have a propagation type parameter in the @Transaction annotation that specifies the requirements about the transactional context in which the method can be called and how it creates, appends, or suspends an ongoing transaction.</p>
    </div>

    <div class="paragraph">
      <p>When an instance that contains transactional methods is injected, Spring uses proxy objects to wrap these methods with the actual transaction code.</p>
    </div>

    <div class="paragraph">
      <p>However, if a transactional method is called from another method in the same class, the this argument is used as the receiver instance instead of the injected proxy object, which bypasses the wrapper code.
      This results in specific transitions from one transactional method to another, which are not allowed:</p>
    </div>

    <table class="tableblock frame-all grid-all stretch">
      <thead>
        <tr>
          <th class="tableblock halign-center valign-top">From</th>
          <th class="tableblock halign-center valign-top">To</th>
        </tr>
      </thead>

      <tbody>
        <tr>
          <td class="tableblock halign-center valign-top"><p class="tableblock">non-\`@Transactional</p></td>
          <td class="tableblock halign-center valign-top"><p class="tableblock">MANDATORY, NESTED, REQUIRED, REQUIRES\_NEW</p></td>
        </tr>

        <tr>
          <td class="tableblock halign-center valign-top"><p class="tableblock">MANDATORY</p></td>
          <td class="tableblock halign-center valign-top"><p class="tableblock">NESTED, NEVER, NOT\_SUPPORTED, REQUIRES\_NEW</p></td>
        </tr>

        <tr>
          <td class="tableblock halign-center valign-top"><p class="tableblock">NESTED</p></td>
          <td class="tableblock halign-center valign-top"><p class="tableblock">NESTED, NEVER, NOT\_SUPPORTED, REQUIRES\_NEW</p></td>
        </tr>

        <tr>
          <td class="tableblock halign-center valign-top"><p class="tableblock">NEVER</p></td>
          <td class="tableblock halign-center valign-top"><p class="tableblock">MANDATORY, NESTED, REQUIRED, REQUIRES\_NEW</p></td>
        </tr>

        <tr>
          <td class="tableblock halign-center valign-top"><p class="tableblock">NOT\_SUPPORTED</p></td>
          <td class="tableblock halign-center valign-top"><p class="tableblock">MANDATORY, NESTED, REQUIRED, REQUIRES\_NEW</p></td>
        </tr>

        <tr>
          <td class="tableblock halign-center valign-top"><p class="tableblock">REQUIRED or @Transactional\`</p></td>
          <td class="tableblock halign-center valign-top"><p class="tableblock">NESTED, NEVER, NOT\_SUPPORTED, REQUIRES\_NEW</p></td>
        </tr>

        <tr>
          <td class="tableblock halign-center valign-top"><p class="tableblock">REQUIRES\_NEW</p></td>
          <td class="tableblock halign-center valign-top"><p class="tableblock">NESTED, NEVER, NOT\_SUPPORTED, REQUIRES\_NEW</p></td>
        </tr>

        <tr>
          <td class="tableblock halign-center valign-top"><p class="tableblock">SUPPORTS</p></td>
          <td class="tableblock halign-center valign-top"><p class="tableblock">MANDATORY, NESTED, NEVER, NOT\_SUPPORTED, REQUIRED, REQUIRES\_NEW</p></td>
        </tr>
      </tbody>
    </table>

    <CodeGroup>
      ```java Bad theme={null}
      public void doTheThing() {
      // ...
      actuallyDoTheThing(); // Noncompliant, call from non-transactional to transactional
      }

      @Transactional
      public void actuallyDoTheThing() {
      // ...
      }
      ```

      ```java Fix theme={null}
      @Transactional
      public void doTheThing() {
      // ...
      actuallyDoTheThing(); // Compliant
      }

      @Transactional
      public void actuallyDoTheThing() {
      // ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title=".equals() should not be used to test the values of Atomic classes">
    <div class="paragraph">
      <p>The equals method in AtomicInteger and AtomicLong returns true only if two instances are identical, not if they represent the same number value.</p>
    </div>

    <div class="paragraph">
      <p>This is because equals is not part of the API contract of these classes, and they do not override the method inherited from java.lang.Object.
      Although both classes implement the Number interface, assertions about equals comparing number values are not part of that interface either.
      Only the API contract of implementing classes like Integer, Long, Float, BigInteger, etc., provides such assertions.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      Boolean isSameNumberValue(AtomicLong a, AtomicLong b) {
      return a.equals(b); // Noncompliant, this is true only if a == b
      }

      Boolean isSameReference(AtomicLong a, AtomicLong b) {
      return a.equals(b); // Noncompliant, because misleading
      }
      ```

      ```java Fix theme={null}
      Boolean isSameNumberValue(AtomicLong a, AtomicLong b) {
      return a.get() == b.get(); // Compliant
      }

      Boolean isSameReference(AtomicLong a, AtomicLong b) {
      return a == b; // Compliant
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="@RequestMapping methods should not be private">
    <div class="paragraph">
      <p>A method with a \`@RequestMapping annotation part of a class annotated with @Controller (directly or indirectly through a meta annotation - @RestController from Spring Boot is a good example) will be called to handle matching web requests. That will happen even if the method is private, because Spring invokes such methods via reflection, without checking visibility.</p>
    </div>

    <div class="paragraph">
      <p>So marking a sensitive method private may seem like a good way to control how such code is called. Unfortunately, not all Spring frameworks ignore visibility in this way. For instance, if you’ve tried to control web access to your sensitive, private, @RequestMapping method by marking it @Secured …​ it will still be called, whether or not the user is authorized to access it. That’s because AOP proxies are not applied to private methods.</p>
    </div>

    <div class="paragraph">
      <p>In addition to @RequestMapping, this rule also considers the annotations introduced in Spring Framework 4.3: @GetMapping, @PostMapping, @PutMapping, @DeleteMapping, @PatchMapping\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @RequestMapping("/greet", method = GET)
      private String greet(String greetee) {  // Noncompliant
      ```

      ```java Fix theme={null}
      @RequestMapping("/greet", method = GET)
      public String greet(String greetee) {
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Use record pattern instead of explicit field access">
    <div class="paragraph">
      <p>Java 21 enhances Pattern Matching, introduced in Java 16, with a <em>record pattern</em> that decomposes records into local variables.
      This form should be used when all fields of a record are accessed within a block for improved readability.
      Nested record patterns are also allowed and should be used when a record field is another record, and all its fields are accessed.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      record Point(Float x, Float y, Float z) {}

      void print(Object obj) {
      if (obj instanceof Point p) { // Noncompliant, because all three fields x, y, z are accessed
          Float x = p.x;
          Float y = p.y();
          System.out.println(x + y + p.z);
      }
      }
      ```

      ```java Fix theme={null}
      record Point(Float x, Float y, Float z) {}

      void print(Object obj) {
      if (obj instanceof Point(Float x, Float y, Float z)) { // Compliant
          System.out.println(x + y + z);
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Loops with at most one iteration should be refactored">
    <div class="paragraph">
      <p>A loop with at most one iteration is equivalent to an if statement.
      This can confuse developers and make the code less readable since loops are not meant to replace if statements.</p>
    </div>

    <div class="paragraph">
      <p>If the intention was to conditionally execute the block only once, an if statement should be used instead.
      Otherwise, the loop should be fixed so the loop block can be executed multiple times.</p>
    </div>

    <div class="paragraph">
      <p>A loop statement with at most one iteration can happen when a statement that unconditionally transfers control,
      such as a jump or throw statement, is misplaced inside the loop block.</p>
    </div>

    <div class="paragraph">
      <p>This rule arises when the following statements are misplaced:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>break</p>
        </li>

        <li>
          <p>return</p>
        </li>

        <li>
          <p>throw</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      int i = 0;
      while(i < 10) { // Noncompliant; loop only executes once
      System.out.println("i is " + i);
      i++;
      break;
      }
      ```

      ```java Fix theme={null}
      for (int i = 0; i < 10; i++) { // Noncompliant; loop only executes once
      if (i == x) {
      break;
      } else {
      System.out.println("i is " + i);
      return;
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Gratuitous comparators should not be created">
    <div class="paragraph">
      <p>With Java 8, there’s no need to write \`Comparators that compare primitive values or other Comparables; they can be generated for you using the Comparator.comparing\* functions: comparing, comparingDouble, comparingInt, comparingLong.</p>
    </div>

    <div class="paragraph">
      <p><strong>Note</strong> that this rule is automatically disabled when the project’s sonar.java.source is lower than 8\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      unparsedFiles.stream()
      .sorted((f1, f2) -> f1.lines - f2.lines)  // Noncompliant
      .limit(30);
      ```

      ```java Fix theme={null}
      unparsedFiles.stream()
      .sorted(Comparator.comparingInt(UnparsedFile::getLines()))
      .limit(30);
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Classes should not depend on an excessive number of classes (aka Monster Class)">
    <div class="paragraph">
      <p>Monster Classes become monolithic entities, with numerous responsibilities and functionalities packed into a single class. This is problematic because it violates the Single Responsibility Principle, which states that a class should have only one reason to change.</p>
    </div>

    <div class="paragraph">
      <p>When a class has too many responsibilities and functionalities, it becomes difficult to maintain. Changes to one part of the class can unintentionally affect other parts, leading to bugs. Additionally, it can be difficult to test the class, as there may be many different interactions between different parts of the class that need to be considered.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      class Foo { // class Foo depends on too many classes: T1, T2, T3, T4, T5, T6 and T7
      T1 t1;
      T2 t2;
      T3 t3;

      public T4 compute(T5 a, T6 b) {
      T7 result = a.getResult(b);
      return (T4) result;
      }
      }
      ```

      ```java Fix theme={null}
      public class Bar {
      T8 a8;
      T9 a9;
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="interface instances should not be cast to concrete types">
    <div class="paragraph">
      <p>Needing to cast from an <code>interface to a concrete type indicates that something is wrong with the abstractions in use, likely that something is missing from the interface. Instead of casting to a discrete type, the missing functionality should be added to the interface</code>. Otherwise there is the risk of runtime exceptions.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public interface MyInterface {
      void doStuff();
      }

      public class MyClass1 implements MyInterface {
      int data;
      public void DoStuff()  {
      // TODO...
      }
      }

      public static class DowncastExampleProgram {
      static void EntryPoint(MyInterface interfaceRef) {
      MyClass1 class1 = (MyClass1)interfaceRef;  // Noncompliant
      int privateData = class1.data;
      }
      }
      ```

      ```java Fix theme={null}
      static void EntryPoint(IMyInterface interfaceRef)
      {
      Object o = (Object)interfaceRef;
      ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Proper Sensor Resource Management">
    <div class="paragraph">
      <p>Optimizing resource usage and preventing unnecessary battery drain are critical considerations in Android development.
      Failing to release sensor resources when they are no longer needed can lead to prolonged device activity, negatively impacting battery life.
      Common Android sensors, such as cameras, GPS, and microphones, provide a method to release resources after they are not in use anymore.</p>
    </div>

    <div class="paragraph">
      <p>This rule identifies situations where a sensor is not released after being utilized, helping developers maintain efficient and battery-friendly applications.</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>Missing call to release() method:</p>

          <div class="ulist">
            <ul>
              <li>
                <p>android.os.PowerManager.WakeLock</p>
              </li>

              <li>
                <p>android.net.wifi.WifiManager\$MulticastLock</p>
              </li>

              <li>
                <p>android.hardware.Camera</p>
              </li>

              <li>
                <p>android.media.MediaPlayer</p>
              </li>

              <li>
                <p>android.media.MediaRecorder</p>
              </li>

              <li>
                <p>android.media.SoundPool</p>
              </li>

              <li>
                <p>android.media.audiofx.Visualizer</p>
              </li>

              <li>
                <p>android.hardware.display.VirtualDisplay</p>
              </li>
            </ul>
          </div>
        </li>

        <li>
          <p>Missing call to close() method</p>

          <div class="ulist">
            <ul>
              <li>
                <p>android.hardware.camera2.CameraDevice</p>
              </li>
            </ul>
          </div>
        </li>

        <li>
          <p>Missing call to removeUpdates() method:</p>

          <div class="ulist">
            <ul>
              <li>
                <p>android.location.LocationManager</p>
              </li>
            </ul>
          </div>
        </li>

        <li>
          <p>Missing call to unregisterListener() method:</p>

          <div class="ulist">
            <ul>
              <li>
                <p>android.hardware.SensorManager</p>
              </li>
            </ul>
          </div>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      public void method() {
      PowerManager powerManager = (PowerManager) getSystemService(POWER_SERVICE);
      PowerManager.WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "My Wake Lock");
      wakeLock.acquire(); // Noncompliant
      // do some work...
      }
      ```

      ```java Fix theme={null}
      public void method() {
      PowerManager powerManager = (PowerManager) getSystemService(POWER_SERVICE);
      PowerManager.WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "My Wake Lock");
      wakeLock.acquire(); // Compliant
      // do some work...
      wakeLock.release();
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="enum fields should not be publicly mutable">
    <div class="paragraph">
      <p><code>enums are generally thought of as constant, but an enum with a public field or public setter is non-constant. Ideally fields in an enum are private</code> and set in the constructor, but if that’s not possible, their visibility should be reduced as much as possible.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public enum Continent {

      NORTH_AMERICA (23, 24709000),
      // ...
      EUROPE (50, 39310000);

      public int countryCount;  // Noncompliant
      private int landMass;

      Continent(int countryCount, int landMass) { 
      // ...
      }

      public void setLandMass(int landMass) {  // Noncompliant
      this.landMass = landMass;
      }
      ```

      ```java Fix theme={null}
      public enum Continent {

      NORTH_AMERICA (23, 24709000),
      // ...
      EUROPE (50, 39310000);

      private int countryCount; 
      private int landMass;

      Continent(int countryCount, int landMass) { 
      // ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Sets with elements that are enum values should be replaced with EnumSet">
    <div class="paragraph">
      <p>When all the elements in a Set are values from the same enum, the Set can be replaced with an EnumSet, which can be much more efficient than other sets because the underlying data structure is a simple bitmap.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class MyClass {

      public enum COLOR {
      RED, GREEN, BLUE, ORANGE;
      }

      public void doSomething() {
      Set<COLOR> warm = new HashSet<COLOR>();
      warm.add(COLOR.RED);
      warm.add(COLOR.ORANGE);
      }
      }
      ```

      ```java Fix theme={null}
      public class MyClass {

      public enum COLOR {
      RED, GREEN, BLUE, ORANGE;
      }

      public void doSomething() {
      Set<COLOR> warm = EnumSet.of(COLOR.RED, COLOR.ORANGE);
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="null should not be returned to indicate exceptional behavior">
    <div class="paragraph">
      <p>Returning <code>null</code> when something goes wrong instead of throwing an exception leaves callers with no understanding of what went wrong. Instead, an exception should be thrown.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public MyClass readFile(String fileName) {
      MyClass mc;
      try {
      // read object from file
      } catch (IOException e) {
      // do cleanup
      return null;  // Noncompliant; why did this fail?
      }
      return mc;
      }
      ```

      ```java Fix theme={null}
      public MyClass readFile(String fileName) throws IOException{
      MyClass mc;
      try {
      // read object from file
      } catch (IOException e) {
      // do cleanup
      throw e;
      }
      return mc;
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="JEE applications should delegate connection management to the container">
    <div class="paragraph">
      <p>The JEE standard forbids the direct management of connections in JEE applications.
      The application code should not directly create, manage, or close database connections.
      Instead, the application code should use the connection pool managed by the container via DataSource objects.</p>
    </div>

    <div class="paragraph">
      <p>The container is responsible for creating and managing the connection pool,
      as well as monitoring the usage of connections and releasing them when they are no longer needed.
      By delegating connection management to the container, JEE applications can avoid connection leaks and resource exhaustion and ensure that database connections are used efficiently and securely.</p>
    </div>

    <div class="paragraph">
      <p>When an application manages connections directly, connection leaks may arise.
      These leaks occur when an application fails to release a database connection after it has finished using it.
      Another risk is vulnerability to SQL injection attacks, which occur when an attacker is able to inject malicious SQL code
      into an application’s database queries, allowing them to access or modify sensitive data.
      Finally, these applications have difficulty managing and monitoring database connections.
      Without a centralized connection pool, tracking the usage of database connections and ensuring they are used efficiently and securely can be challenging.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue for using a DriverManager in a servlet class.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      private static final String CONNECT_STRING = "jdbc:mysql://localhost:3306/mysqldb";

      public void doGet(HttpServletRequest req, HttpServletResponse res)
      throws ServletException, IOException  {

      Connection conn = null;
      try {
      conn = DriverManager.getConnection(CONNECT_STRING);  // Noncompliant
      // ...
      } catch (SQLException ex) {...}
      //...
      }
      }
      ```

      ```java Fix theme={null}
      private static final String DB_LOOKUP = "jdbc/mainDb";

      public void doGet(HttpServletRequest req, HttpServletResponse res)
      throws ServletException, IOException  {

      Connection conn = null;
      try {
      InitialContext ctx = new InitialContext();
      DataSource datasource = (DataSource) ctx.lookup(DB_LOOKUP);
      conn = datasource.getConnection();
      // ...
      } catch (SQLException ex) {...}
      //...
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Permitted types of a sealed class should be omitted if they are declared in the same file">
    <div class="paragraph">
      <p>\`sealed classes were introduced in Java 17. This feature is very useful if there is a need to define a strict hierarchy and restrict the possibility of extending classes. In order to mention all the allowed subclasses, there is a keyword permits, which should be followed by subclasses' names.</p>
    </div>

    <div class="paragraph">
      <p>This notation is quite useful if subclasses of a given sealed class can be found in different files, packages, or even modules. In case when all subclasses are declared in the same file there is no need to mention the explicitly and permits part of a declaration can be omitted.</p>
    </div>

    <div class="paragraph">
      <p>This rule reports an issue if all subclasses of a sealed\` class are declared in the same file as their superclass.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      sealed class A permits B, C, D, E {} // Noncompliant
      final class B extends A {}
      final class C extends A {}
      final class D extends A {}
      final class E extends A {}
      ```

      ```java Fix theme={null}
      sealed class A {} // Compliant
      final class B extends A {}
      final class C extends A {}
      final class D extends A {}
      final class E extends A {}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Call to Mockito method verify, when or given should be simplified">
    <div class="paragraph">
      <p>Mockito provides <em>argument matchers</em> for flexibly stubbing or verifying method calls.</p>
    </div>

    <div class="paragraph">
      <p>\`Mockito.verify(), Mockito.when(), Stubber.when() and BDDMockito.given() each have overloads with and without argument matchers.</p>
    </div>

    <div class="paragraph">
      <p>However, the default matching behavior (i.e. without argument matchers) uses equals(). If only the matcher org.mockito.ArgumentMatchers.eq() is used, the call is equivalent to the call without matchers, i.e. the eq()\` is not necessary and can be omitted. The resulting code is shorter and easier to read.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @Test
      public void myTest() {
      given(foo.bar(eq(v1), eq(v2), eq(v3))).willReturn(null);   // Noncompliant
      when(foo.baz(eq(v4), eq(v5))).thenReturn("foo");   // Noncompliant
      doThrow(new RuntimeException()).when(foo).quux(eq(42));    // Noncompliant
      verify(foo).bar(eq(v1), eq(v2), eq(v3));   // Noncompliant
      }
      ```

      ```java Fix theme={null}
      @Test
      public void myTest() {
      given(foo.bar(v1, v2, v3)).willReturn(null);
      when(foo.baz(v4, v5)).thenReturn("foo");
      doThrow(new RuntimeException()).when(foo).quux(42);
      verify(foo).bar(v1, v2, v3);
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Methods with Spring proxying annotations should be public">
    <div class="paragraph">
      <p>Marking a non-public method @Async or @Transactional is misleading because Spring does not recognize non-public methods, and so makes no provision for their proper invocation.
      Nor does Spring make provision for the methods invoked by the method it called.</p>
    </div>

    <div class="paragraph">
      <p>Therefore marking a private method, for instance, @Transactional can only result in a runtime error or exception if the method is annotated as @Transactional.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      @Async
      private Future<String> asyncMethodWithReturnType() { // Noncompliant, no proxy generated and
      return "Hellow, world!";                         // can only be invoked from same class
      }
      ```

      ```java Fix theme={null}
      @Async
      public Future<String> asyncMethodWithReturnType() { // Compliant
      return "Hellow, world!";
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Unnecessary semicolons should be omitted">
    <div class="paragraph">
      <p>Under the reasoning that cleaner code is better code, the semicolon at the end of a try-with-resources construct should be omitted because it can be omitted.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      try (ByteArrayInputStream b = new ByteArrayInputStream(new byte[10]);  // ignored; this one's required
        Reader r = new InputStreamReader(b);)   // Noncompliant
      {
      //do stuff
      }
      ```

      ```java Fix theme={null}
      try (ByteArrayInputStream b = new ByteArrayInputStream(new byte[10]);
        Reader r = new InputStreamReader(b))
      {
      //do stuff
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Object.wait should not be called on objects that implement java.util.concurrent.locks.Condition">
    <div class="paragraph">
      <p>The java.util.concurrent.locks.Condition interface provides an alternative to the Object monitor methods (wait, notify and notifyAll).
      Hence, the purpose of implementing said interface is to gain access to its more nuanced await methods.</p>
    </div>

    <div class="paragraph">
      <p>Consequently, calling the method Object.wait on a class implementing the Condition interface is contradictory and should be avoided. Use Condition.await instead.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      void doSomething(Condition condition) {
      condition.wait(); // Noncompliant, Object.wait is called

          ...
      }
      ```

      ```java Fix theme={null}
      void doSomething(Condition condition) {
      condition.await(); // Compliant, Condition.await is called

          ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Modifiers should be declared in the correct order">
    <div class="paragraph">
      <p>The Java Language Specification recommends listing modifiers in the following order:</p>
    </div>

    <div class="olist arabic">
      <ol class="arabic">
        <li>
          <p>Annotations</p>
        </li>

        <li>
          <p>public</p>
        </li>

        <li>
          <p>protected</p>
        </li>

        <li>
          <p>private</p>
        </li>

        <li>
          <p>abstract</p>
        </li>

        <li>
          <p>static</p>
        </li>

        <li>
          <p>final</p>
        </li>

        <li>
          <p>transient</p>
        </li>

        <li>
          <p>volatile</p>
        </li>

        <li>
          <p>synchronized</p>
        </li>

        <li>
          <p>native</p>
        </li>

        <li>
          <p>default</p>
        </li>

        <li>
          <p>strictfp</p>
        </li>
      </ol>
    </div>

    <div class="paragraph">
      <p>Not following this convention has no technical impact, but will reduce the code’s readability because most developers are used to the standard order.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      static public void main(String[] args) {   // Noncompliant
      }
      ```

      ```java Fix theme={null}
      public static void main(String[] args) {   // Compliant
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title=".length should be used to test for the emptiness of StringBuffers">
    <div class="paragraph">
      <p>Assembling a <code>StringBuilder or StringBuffer into a String merely to see if it’s empty is a waste of cycles. Instead, jump right to the heart of the matter and get its .length()</code> instead.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      StringBuilder sb = new StringBuilder();
      // ...
      if ("".equals(sb.toString()) { // Noncompliant
      // ...
      }
      ```

      ```java Fix theme={null}
      StringBuilder sb = new StringBuilder();
      // ...
      if (sb.length() == 0) {
      // ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Test signatures should not include superfluous throws declarations">
    <div class="paragraph">
      <p>An exception in a \`throws declaration in Java is superfluous if it is:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>listed multiple times</p>
        </li>

        <li>
          <p>a subclass of another listed exception</p>
        </li>

        <li>
          <p>a RuntimeException\`, or one of its descendants</p>
        </li>

        <li>
          <p>completely unnecessary because the declared exception type cannot actually be thrown</p>
        </li>
      </ul>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      void foo() throws MyException {
      throw new MyException();
      }

      @Test
      public void testMethod1() throws MyException, MyException {  // Noncompliant; should be listed once
      foo();
      }

      @Test  
      public void testMethod2() throws MyException { //Noncompliant, exception cannot be thrown
      }

      @Test
      public void testMethod3() throws Throwable, Exception {}  // Noncompliant; Exception is a subclass of Throwable

      @Test
      public void testMethod4 throws RuntimeException {}  // Noncompliant; RuntimeException can always be thrown
      ```

      ```java Fix theme={null}
      @Test
      public void testMethod1() throws MyException {
      foo();
      }

      @Test  
      public void testMethod2() {
      }

      @Test
      public void testMethod3()throws Throwable {}

      @Test
      public void testMethod4() {}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="StringBuilder and StringBuffer should not be instantiated with a character ">
    <div class="paragraph">
      <p>When a developer uses the StringBuilder or StringBuffer constructor with a single character as an argument,
      the likely intention is to create an instance with the character as the initial string value.</p>
    </div>

    <div class="paragraph">
      <p>However, this is not what happens because of the absence of a dedicated StringBuilder(char) or StringBuffer(char) constructor.
      Instead, StringBuilder(int) or StringBuffer(int) is invoked,
      which results in an instance with the provided int value as the initial capacity of the StringBuilder or StringBuffer.</p>
    </div>

    <div class="paragraph">
      <p>The reason behind this behavior lies in the automatic widening of char expressions to int when required.
      Consequently, the UTF-16 code point value of the character (for example, 65 for the character 'A')
      is interpreted as an int to specify the initial capacity.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      StringBuffer foo = new StringBuffer('x'); // Noncompliant, replace with String
      ```

      ```java Fix theme={null}
      StringBuffer foo = new StringBuffer("x"); // Compliant
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="@PathVariable annotation should be present if a path variable is used">
    <div class="paragraph">
      <p>The @PathVariable annotation in Spring extracts values from the URI path and binds them to method parameters in a Spring MVC controller.
      It is commonly used with @GetMapping, @PostMapping, @PutMapping, and @DeleteMapping to capture path variables from the URI.
      These annotations map HTTP requests to specific handler methods in a controller.
      They are part of the Spring Web module and are commonly used to define the routes for different HTTP operations in a RESTful API.</p>
    </div>

    <div class="paragraph">
      <p>If a method has a path template containing a placeholder, like "/api/resource/\{id}", and there’s no @PathVariable annotation on a method parameter to capture the id path variable, Spring will disregard the id variable.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      @GetMapping("/api/resource/{id}")
      public ResponseEntity<String> getResourceById(Long id) { // Noncompliant - The 'id' parameter will not be automatically populated with the path variable value
      return ResponseEntity.ok("Fetching resource with ID: " + id);
      }
      ```

      ```java Fix theme={null}
      @GetMapping("/api/resource/{id}")
      public ResponseEntity<String> getResourceById(@PathVariable Long id) { // Compliant
      return ResponseEntity.ok("Fetching resource with ID: " + id);
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Hash-based collections with known capacity should be initialized with the proper related static method.">
    <div class="paragraph">
      <p>When creating an instance of HashMap or HashSet, the developer can pick a constructor with known capacity.
      However, the requested capacity is not fully allocated by default.
      Indeed, when the collection reaches the load factor of the collection (default: 0.75), the collection is resized on the fly, leading to unexpected performance issues.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      private static final int KNOWN_CAPACITY = 1_000_000;

      public static Map<String, Integer> buildAMap() {
      return new HashMap<>(KNOWN_CAPACITY); // Noncompliant
      }

      public static Set<String> buildASet() {
      return new HashSet<>(KNOWN_CAPACITY); // Noncompliant
      }
      ```

      ```java Fix theme={null}
      private static final int KNOWN_CAPACITY = 1_000_000;

      public static Map<String, Integer> buildABetterMap() {
      return HashMap.newHashMap(KNOWN_CAPACITY);
      }

      public static Set<String> buildABetterSet() {
      return HashSet.newHashSet(KNOWN_CAPACITY);
      }

      public static Set<String> buildABetterSet(float customLoadFactor) {
      return new HashSet<>(KNOWN_CAPACITY, customLoadFactor);
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Records should be used to return more than one value from a method">
    <div class="paragraph">
      <p>Sometimes when implementing a method, there is a need to return more than one value. To reduce the boilerplate of describing another class, other programming languages introduced such structures as \`Pair, Tuple, Vector, etc.</p>
    </div>

    <div class="literalblock">
      <div class="content">
        <pre>Unfortunately, in Java, there is no such structure and ++Map.Entry++ or ++Object\[]++ of fixed size are used as a workaround for returning multiple values from a method.</pre>
      </div>
    </div>

    <div class="paragraph">
      <p>Java 16 introduced records to represent immutable data structures and they can be used for grouping different values in one entity. By using records, developers will have meaningful names and result in a more readable code. Furthermore, when using Object\[], there is a risk of getting ClassCastException or ArrayIndexOutOfBoundsException if not used carefully. It means that using records is not only more readable but is definitely safer.</p>
    </div>

    <div class="paragraph">
      <p>This rule should report an issue when Object\[] of a fixed size (\< 7) or Map.Entry\` are returned from a <strong>private</strong> method.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      private Map.Entry<String, Integer> getPerson() {
      String name = "John";
      int age = 25;
      return Map.entry(name, age); // Noncompliant
      }

      private Object[] getPerson() {
      Object[] result = new Object[2];
      result[0] = "John";
      result[1] = 25;
      return result; // Noncompliant
      }
      ```

      ```java Fix theme={null}
      record Person(String name, int age) {}

      Person getPerson() {
      String name = "John";
      int age = 25;
      return new Person(name, age); // Compliant
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="clone should not be overridden">
    <div class="paragraph">
      <p>The Object.clone / java.lang.Cloneable mechanism in Java should be considered broken for the following reasons and should, consequently, not be used:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>Cloneable is a <em>marker interface</em> without API but with a contract about class behavior that the compiler cannot enforce. This is a bad practice.</p>
        </li>

        <li>
          <p>Classes are instantiated without calling their constructor, so possible preconditions cannot be enforced.</p>
        </li>

        <li>
          <p>There are implementation flaws by design when overriding Object.clone, like type casts or the handling of CloneNotSupportedException exceptions.</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      class Entity implements Cloneable { // Noncompliant, using `Cloneable`

      public int value;
      public List<Entity> children; // deep copy wanted

      Entity() {
      EntityManager.register(this); // invariant
      }

      @Override
      public Entity clone() {
      try {
        Entity copy = (Entity) super.clone(); // invariant not enforced, because no constructor is caled
        copy.children = children.stream().map(Entity::clone).toList();
        return copy;
      } catch (CloneNotSupportedException e) { // this will not happen due to behavioral contract
        throw new AssertionError();
      }
      }
      }
      ```

      ```java Fix theme={null}
      class Entity { // Compliant

      public int value;
      public List<Entity> children; // deep copy wanted

      Entity() {
      EntityManager.register(this); // invariant
      }

      Entity(Entity template) {
      value = template.value;
      children = template.children.stream().map(Entity::new).toList();
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="PreparedStatements should be used">
    <div class="paragraph">
      <p>\`PreparedStatements and CallableStatements (for stored procedures) are safer and more efficient than Statements and should always be preferred.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue each time a Statement\` is declared.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Statement stmt = null;  // Noncompliant
      // ...
      ```

      ```java Fix theme={null}
      PreparedStatement stmt = null;
      // ...
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Declarations should use Java collection interfaces such as List rather than specific implementation classes such as LinkedList">
    <div class="paragraph">
      <p>The Java Collections API offers a well-structured hierarchy of interfaces
      designed to hide collection implementation details.
      For the various collection data structures like lists, sets, and maps,
      specific interfaces (java.util.List, java.util.Set, java.util.Map)
      cover the essential features.</p>
    </div>

    <div class="paragraph">
      <p>When passing collections as method parameters, return values, or when exposing fields,
      it is generally recommended to use these interfaces instead of the implementing classes.
      The implementing classes, such as java.util.LinkedList, java.util.ArrayList,
      and java.util.HasMap, should only be used for collection instantiation.
      They provide finer control over the performance characteristics of those structures,
      and developers choose them depending on their use case.</p>
    </div>

    <div class="paragraph">
      <p>For example, if fast random element access is essential, java.util.ArrayList should be instantiated.
      If inserting elements at a random position into a list is crucial, a java.util.LinkedList should be preferred.
      However, this is an implementation detail your API should not expose.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class Employees {
      public final HashSet<Employee> employees   // Noncompliant, field type should be "Set"
      = new HashSet<Employee>();

      public HashSet<Employee> getEmployees() {  // Noncompliant, return type should be "Set"
      return employees;
      }
      }
      ```

      ```java Fix theme={null}
      public class Employees {
      public final Set<Employee> employees       // Compliant
      = new HashSet<Employee>();

      public Set<Employee> getEmployees() {      // Compliant
      return employees;
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Singletons should be implemented as enums">
    <div class="paragraph">
      <p>There are many ways to implement the Singleton pattern in Java, but none of them is as clean, compact and close to fool-proof as using an <code>enum. Without an enum, the implementer must take care to properly handle thread-safety, serialization, and classloaders, but those things come for free with an enum</code>.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class Highlander implements Serializable { // Serializable makes Singleton tricky to get right
      private static final Highlander INSTANCE;

      public static synchronized Highlander getInstance() {
      if(INSTANCE == null) {
        INSTANCE = new Highlander();
      }
      return INSTANCE;
      }

      private Highlander () {}

      private final String [] rivals = {"The Kurgan", "Ramirez"}; // oops, not serializable now

      private Object readResolve() { 
      return INSTANCE;
      }

      ...
      }
      ```

      ```java Fix theme={null}
      public enum Highlander {
      INSTANCE;

      private final String [] rivals = {"The Kurgan", "Ramirez"};

      ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="JEE applications should not use sockets">
    <div class="paragraph">
      <p>According to the EJB specification:</p>
    </div>

    <div class="quoteblock">
      <blockquote>
        <div class="paragraph">
          <p>An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.</p>
        </div>

        <div class="paragraph">
          <p>…​</p>
        </div>

        <div class="ulist">
          <ul>
            <li>
              <p>The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.</p>
            </li>
          </ul>
        </div>

        <div class="paragraph">
          <p>These networking functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security and decrease the container’s ability to properly manage the runtime environment.</p>
        </div>
      </blockquote>
    </div>

    <div class="paragraph">
      <p>Since EJB’s may be passivated (temporarily serialized at the discretion of the container), using sockets in an EJB could cause resource leaks. Instead, you should work at a higher level and let the container handle such resources.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue each time a socket is created or or retrieved from another class in a servlet class or EJB.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
      // ...

      Socket sock = null;
      try {
      sock = new Socket(host, 3000);  // Noncompliant
      // ...
      } catch (Exception e) {
      // ...
      }
      }
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Track lack of required properties">
    <div class="paragraph">
      <p>This rule raises an issue when required properties are not included in a project’s pom.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      <project //...>
      <division>
      <name>Manufacturing</name>
      </division>

      <!-- ... -->
      </project>
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Use when instead of a single if inside a pattern match body">
    <div class="paragraph">
      <p>Java 21 has introduced enhancements to switch statements and expressions, allowing them to operate on any type, not just specific ones, as in previous versions.
      Furthermore, case labels have been upgraded to support patterns, providing an alternative to the previous restriction of only accepting constants.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      // As of Java 21
      String patternMatchSwitch(Object obj) {
      return switch (obj) {
          case String s  -> String.format("String %s", s);
          case Integer i -> String.format("int %d", i);
          default        -> obj.toString();
      };
      }
      ```

      ```java Fix theme={null}
      String guardedCaseSwitch(Object obj) {
      return switch (obj) {
          case String s when s.length() > 0 -> String.format("String %s", s);
          case Integer i when i > 0 -> String.format("int %d", i);
          default        -> obj.toString();
      };
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="== and != should not be used when equals is overridden">
    <div class="paragraph">
      <p>It is equivalent to use the equality \`== operator and the equals method to compare two objects if the equals method inherited from Object has not been overridden. In this case both checks compare the object references.</p>
    </div>

    <div class="paragraph">
      <p>But as soon as equals is overridden, two objects not having the same reference but having the same value can be equal. This rule spots suspicious uses of == and != operators on objects whose equals\` methods are overridden.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      String firstName = getFirstName(); // String overrides equals 
      String lastName = getLastName();

      if (firstName == lastName) { ... }; // Non-compliant; false even if the strings have the same value
      ```

      ```java Fix theme={null}
      String firstName = getFirstName();
      String lastName = getLastName();

      if (firstName != null && firstName.equals(lastName)) { ... };
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="JAXBContext instances should be reused">
    <div class="paragraph">
      <p>The creation of a <code>JAXBContext.newInstance is a costly operation, and should only be performed once per context and stored - preferably in a static</code> member - for reuse.</p>
    </div>

    <div class="paragraph">
      <p>In fact, according to the JAXB 2.2 Specification:</p>
    </div>

    <div class="quoteblock">
      <blockquote>
        <div class="paragraph">
          <p>To avoid the overhead involved in creating a JAXBContext instance, a JAXB application is encouraged to reuse a JAXBContext instance. An implementation of abstract class JAXBContext is required to be thread-safe, thus, multiple threads in an application can share the same JAXBContext instance.</p>
        </div>
      </blockquote>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when multiple instances are created for the same context path.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public void doSomething(List<MyObj> inputs) {
      for (String input : inputs) {
      Marshaller m = JAXBContext.newInstance(MyObj.class).createMarshaller();  // Noncompliant; context created in loop
      // ... 
      }
      }

      public List<JAXBContext> getContexts(List<Class> inputs) {
      List<JAXBContext> result = new ArrayList<>();
      for (Class input : inputs) {
      result.add(JAXBContext.newInstance(input);  // Compliant; context path varies
      }
      return result;
      }

      public void doSomething2(List<MyObj> inputs) {
      Marshaller m = JAXBContext.newInstance(MyObj.class).createMarshaller();  // Noncompliant; context created each time method invoked
      for (String input : inputs) {
      // ...
      }
      }
      ```

      ```java Fix theme={null}
      private static JAXBContext context;
      static {
      try {
      context = JAXBContext.newInstance(MyObj.class);
      } catch (JAXBException e) {
      // handle exception...
      }
      }

      public void doSomething(List<MyObj> inputs) {
      Marshaller m = context.createMarshaller();
      for (String input : inputs) {
      // ... 
      }
      }

      public List<JAXBContext> getContexts(List<Class> inputs) {
      List<JAXBContext> result = new ArrayList<>();
      for (Class input : inputs) {
      result.add(JAXBContext.newInstance(input);
      }
      return result;
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Test methods should not contain too many assertions">
    <div class="paragraph">
      <p>A common good practice is to write test methods targeting only one logical concept, that can only fail for one reason.</p>
    </div>

    <div class="paragraph">
      <p>While it might make sense to have more than one assertion to test one concept, having too many is a sign that a test became too complex and should be refactored to multiples ones.</p>
    </div>

    <div class="paragraph">
      <p>This rule will report any test method containing more than a given number of assertion.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @Test
      void test() { // Refactor this method.
      assertEquals(1, f(1));
      assertEquals(2, f(2));
      assertEquals(3, g(1));
      }
      ```

      ```java Fix theme={null}
      void test_f() {
      assertEquals(1, f(1));
      assertEquals(2, f(2));
      }
      void test_g() {
      assertEquals(3, g(1));
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Inner classes which do not reference their owning classes should be static">
    <div class="paragraph">
      <p>A non-static inner class has a reference to its outer class, and access to the outer class' fields and methods. That class reference makes the inner class larger and could cause the outer class instance to live in memory longer than necessary.</p>
    </div>

    <div class="paragraph">
      <p>If the reference to the outer class isn’t used, it is more efficient to make the inner class \`static (also called nested). If the reference is used only in the class constructor, then explicitly pass a class reference to the constructor. If the inner class is anonymous, it will also be necessary to name it.</p>
    </div>

    <div class="paragraph">
      <p>However, while a nested/static class would be more efficient, it’s worth noting that there are semantic differences between an inner class and a nested one:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>an inner class can only be instantiated within the context of an instance of the outer class.</p>
        </li>

        <li>
          <p>a nested (static\`) class can be instantiated independently of the outer class.</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      public class Fruit {
      // ...

      public class Seed {  // Noncompliant; there's no use of the outer class reference so make it static
      int germinationDays = 0;
      public Seed(int germinationDays) {
        this.germinationDays = germinationDays;
      }
      public int getGerminationDays() {
        return germinationDays;
      }
      }
      }
      ```

      ```java Fix theme={null}
      public class Fruit {
      // ...

      public static class Seed {
      int germinationDays = 0;
      public Seed(int germinationDays) {
        this.germinationDays = germinationDays;
      }
      public int getGerminationDays() {
        return germinationDays;
      }
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Cloneables should implement clone">
    <div class="paragraph">
      <p>Cloneable is a <em>marker interface</em> that defines the contract of the Object.clone method,
      which is to create a consistent copy of the instance.
      The clone method is not defined by the interface though, but by class Objects.</p>
    </div>

    <div class="paragraph">
      <p>The general problem with marker interfaces is that their definitions cannot be enforced by the compiler because they have no own API.
      When a class implements Cloneable
      but does not override Object.clone,
      it is highly likely that it violates the contract for Cloneable.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      class Foo implements Cloneable { // Noncompliant, override `clone` method
      public int value;
      }
      ```

      ```java Fix theme={null}
      class Foo implements Cloneable { // Compliant

      public int value;

      @Override
      public Foo clone() {
      try {
        return (Foo) super.clone();
      } catch (CloneNotSupportedException e) {
        throw new AssertionError();
      }
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Tests method should not be annotated with competing annotations">
    <div class="paragraph">
      <p>Annotating unit tests with more than one test-related annotation is not only useless but could also result in unexpected behavior like failing tests or unwanted side-effects.</p>
    </div>

    <div class="paragraph">
      <p>This rule reports an issue when a test method is annotated with more than one of the following competing annotation:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>@Test</p>
        </li>

        <li>
          <p>@RepeatedTest</p>
        </li>

        <li>
          <p>@ParameterizedTest</p>
        </li>

        <li>
          <p>@TestFactory</p>
        </li>

        <li>
          <p>@TestTemplate</p>
        </li>
      </ul>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @Test
      @RepeatedTest(2) // Noncompliant, this test will be repeated 3 times
      void test() { }

      @ParameterizedTest
      @Test
      @MethodSource("methodSource")
      void test2(int argument) { } // Noncompliant, this test will fail with ParameterResolutionException
      ```

      ```java Fix theme={null}
      @RepeatedTest(2)
      void test() { }

      @ParameterizedTest
      @MethodSource("methodSource")
      void test2(int argument) { }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Single property comparators should use Comparator.comparing">
    <div class="paragraph">
      <p>Java 8 adds \`Comparator.comparing to allow the creation of a single-value comparator to be shorthanded into a single call. This cleaner syntax should be preferred.</p>
    </div>

    <div class="paragraph">
      <p><strong>Note</strong> that this rule is automatically disabled when the project’s sonar.java.source is lower than 8\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Comparator<Foo> compartor = (foo1, foo2) -> foo.getName().compareTo(foo2.getName());  // Noncompliant
      ```

      ```java Fix theme={null}
      Comparator<Foo> compartor = Comparator.comparing(Foo::getName);
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Getters annotated for persistence should not contain business logic">
    <div class="paragraph">
      <p>Including any logic other than a simple return of the field in a persistence-annotated method can result in odd behavior, including for example, the default construction of empty members which are annotated to be <code>lazy</code>.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      private Double price;

      @Columm(name="price")
      public Double getPrice() {
      if(buyer.isLoaltyMember()) {  // Noncompliant
      return price - getLoyaltyDiscount();
      } else {
      return price;
      }
      }
      ```

      ```java Fix theme={null}
      @Columm(name="price")
      private Double price;

      public Double getPrice() {
      if(buyer.isLoaltyMember()) {
      return price - getLoyaltyDiscount();
      } else {
      return price;
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Test methods should comply with a naming convention">
    <div class="paragraph">
      <p>Shared naming conventions allow teams to collaborate efficiently. This rule raises an issue when a test method name does not match the provided regular expression.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @Test
      public void foo() {  // Noncompliant
      //...
      }
      ```

      ```java Fix theme={null}
      @Test
      public void testFoo() {
      // ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="AssertJ assertions with Consumer arguments should contain assertion inside consumers">
    <div class="paragraph">
      <p>AssertJ assertions taking \`Consumer objects as arguments are expected to contain "requirements", which should themselves be expressed as assertions. This concerns the following methods: <a href="http://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/AbstractIterableAssert.html#allSatisfy-java.util.function.Consumer-">allSatisfy</a>, <a href="http://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/AbstractIterableAssert.html#anySatisfy-java.util.function.Consumer-">anySatisfy</a>, <a href="http://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/AbstractIterableAssert.html#hasOnlyOneElementSatisfying-java.util.function.Consumer-">hasOnlyOneElementSatisfying</a>, <a href="https://tinyurl.com/yxnzt6pj">isInstanceOfSatisfying</a>, <a href="http://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/AbstractIterableAssert.html#noneSatisfy-java.util.function.Consumer-">noneSatisfy</a>, <a href="http://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/AbstractAssert.html#satisfies-java.util.function.Consumer-">satisfies</a>, <a href="http://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/AbstractAssert.html#satisfiesAnyOf-java.util.function.Consumer-java.util.function.Consumer-">satisfiesAnyOf</a>, <a href="http://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/AbstractIterableAssert.html#zipSatisfy-java.lang.Iterable-java.util.function.BiConsumer-">zipSatisfy</a>.</p>
    </div>

    <div class="paragraph">
      <p>These methods are assuming the Consumer will do the assertions itself. If you do not do any assertion in the Consumer, it probably means that you are inadvertently only partially testing your object.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when a Consumer\` argument of any of the above methods does not contain any assertion.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      assertThat(myObject).isInstanceOfSatisfying(String.class, s -> "Hello".equals(s)); // Noncompliant - not testing the string value
      assertThat(myObject).satisfies("Hello"::equals); // Noncompliant - not testing the string value
      ```

      ```java Fix theme={null}
      assertThat(myObject).isInstanceOfSatisfying(String.class, s -> assertThat(s).isEqualTo("Hello"));
      assertThat(myObject).satisfies(obj -> assertThat(obj).isEqualTo("Hello"));
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="writeObject argument must implement Serializable">
    <div class="paragraph">
      <p>Serialization is a platform-independent mechanism for writing the state of an object into a byte-stream. For serializing the object, we
      call the writeObject() method of java.io.ObjectOutputStream class.
      Only classes that implement Serializable or extend a class that does it can successfully be serialized (or de-serialized).</p>
    </div>

    <div class="paragraph">
      <p>Attempting to write a class with the writeObject method of the ObjectOutputStream class that does not implement Serializable or
      extends a class that implements it, will throw an IOException.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      public class Vegetable {
      // ...
      }

      public class Menu {
      public void meal(ObjectOutputStream oos) throws IOException {
      Vegetable veg = new Vegetable();
      oos.writeObject(veg);  // Noncompliant
      }
      }
      ```

      ```java Fix theme={null}
      public class Vegetable implements Serializable {
      // ...
      }

      public class Menu {
      public void meal(ObjectOutputStream oos) throws IOException {
      Vegetable veg = new Vegetable();
      oos.writeObject(veg);
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="serialVersionUID should not be declared blindly">
    <div class="paragraph">
      <p>Providing a \`serialVersionUID field on Serializable classes is strongly recommended by the Serializable documentation but blindly following that recommendation can be harmful.</p>
    </div>

    <div class="paragraph">
      <p>serialVersionUID value is stored with the serialized data and this field is verified when deserializing the data to ensure that the code reading the data is compatible with the serialized data. In case of failure, it means the serialized data and the code are not in sync and this fine because you know what’s wrong.</p>
    </div>

    <div class="paragraph">
      <p>When the serialVersionUID is generated by an IDE or blindly hard-coded, there is a high probability that one will forget to update the serialVersionUID value when the Serializable class is later enriched with additional fields. As a consequence, old serialized data will incorrectly be considered compatible with the newer version of the code creating situations which are hard to debug.</p>
    </div>

    <div class="paragraph">
      <p>Therefore, defining serialVersionUID should be done with care. This rule raises an issue on each serialVersionUID field declared on classes implementing Serializable to be sure the presence and the value of the serialVersionUID\` field is challenged and validated by the team.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class Foo implements Serializable {
      private static final long serialVersionUID = 1; 
      }

      public class BarException extends RuntimeException {
      private static final long serialVersionUID = 8582433437601788991L;
      }
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Java 8s Files.exists should not be used">
    <div class="paragraph">
      <p>The \`Files.exists method has noticeably poor performance in JDK 8, and can slow an application significantly when used to check files that don’t actually exist.</p>
    </div>

    <div class="paragraph">
      <p>The same goes for Files.notExists, Files.isDirectory and Files.isRegularFile from java.nio.file package.</p>
    </div>

    <div class="paragraph">
      <p><strong>Note</strong> that this rule is automatically disabled when the project’s sonar.java.source\` is not 8.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Path myPath;
      if(java.nio.file.Files.exists(myPath)) {  // Noncompliant
      // do something
      }
      ```

      ```java Fix theme={null}
      Path myPath;
      if(myPath.toFile().exists())) { 
      // do something
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Exception should not be caught when not required by called methods">
    <div class="paragraph">
      <p>Catching \`Exception seems like an efficient way to handle multiple possible exceptions. Unfortunately, it traps all exception types, both checked and runtime exceptions, thereby casting too broad a net. Indeed, was it really the intention of developers to also catch runtime exceptions? To prevent any misunderstanding, if both checked and runtime exceptions are really expected to be caught, they should be explicitly listed in the catch clause.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue if Exception is caught when it is not explicitly thrown by a method in the try\` block.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      try {
      // do something that might throw an UnsupportedDataTypeException or UnsupportedEncodingException
      } catch (Exception e) { // Noncompliant
      // log exception ...
      }
      ```

      ```java Fix theme={null}
      try {
      // do something
      } catch (UnsupportedEncodingException|UnsupportedDataTypeException|RuntimeException e) {
      // log exception ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Mockito argument matchers should be used on all parameters">
    <div class="paragraph">
      <p>Mockito provides <em>argument matchers</em> and <em>argument captors</em> for flexibly stubbing or verifying method calls.</p>
    </div>

    <div class="paragraph">
      <p>Mockito.verify(), Mockito.when(), Stubber.when() and BDDMockito.given() each have overloads with and without argument matchers.</p>
    </div>

    <div class="paragraph">
      <p>However, if argument matchers or captors are used only on some of the parameters, all the parameters need to have matchers as well, otherwise an InvalidUseOfMatchersException will be thrown.</p>
    </div>

    <div class="paragraph">
      <p>This rule consequently raises an issue every time matchers are not used on all the parameters of a stubbed/verified method.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      @Test
      public void myTest() {
      // Setting up mock responses
      given(foo.bar(anyInt(), i1, i2)).willReturn(null); // Noncompliant, no matchers for "i1" and "i2"
      when(foo.baz(eq(val1), val2)).thenReturn("hi"); // Noncompliant, no matcher for "val2"

      // Simulating exceptions
      doThrow(new RuntimeException()).when(foo).quux(intThat(x -> x >= 42), -1); // Noncompliant, no matcher for "-1"

      // Verifying method invocations
      verify(foo).bar(i1, anyInt(), i2); // Noncompliant, no matchers for "i1" and "i2"

      // Capturing arguments for verification
      ArgumentCaptor<Integer> captor = ArgumentCaptor.forClass(Integer.class);
      verify(foo).bar(captor.capture(), i1, any()); // Noncompliant, no matchers for "i1"
      }
      ```

      ```java Fix theme={null}
      @Test
      public void myTest() {
      // Setting up mock responses
      given(foo.bar(anyInt(), eq(i1), eq(i2))).willReturn(null); // Compliant, all arguments have matchers
      when(foo.baz(val1, val2)).thenReturn("hi"); // Compliant, no argument has matchers

      // Simulating exceptions
      doThrow(new RuntimeException()).when(foo).quux(intThat(x -> x >= 42), eq(-1)); // Compliant, all arguments have matchers

      // Verifying method invocations
      verify(foo).bar(eq(i1), anyInt(), eq(i2)); // Compliant, all arguments have matchers

      // Capturing arguments for verification
      ArgumentCaptor<Integer> captor = ArgumentCaptor.forClass(Integer.class);
      verify(foo).bar(captor.capture(), any(), any()); // Compliant, all arguments have matchers
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="setDaemon, setPriority and getThreadGroup should not be invoked on virtual threads">
    <div class="paragraph">
      <p>The Thread class has some methods that are used to monitor and manage its execution.
      With the introduction of virtual threads in Java 21, there are three of these methods that behave differently
      between the standard platform threads and the virtual ones.</p>
    </div>

    <div class="paragraph">
      <p>For virtual threads:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>Thread.setDaemon(boolean) will throw an IllegalArgumentException if false is passed as an argument as a virtual thread daemon status is always true.</p>
        </li>

        <li>
          <p>Thread.setPriority(int priority) will never change the actual priority of a virtual thread, which is always equal to Thread.NORM\_PRIORITY</p>
        </li>

        <li>
          <p>Thread.getThreadGroup() will return a dummy "VirtualThreads" group that is empty and should not be used</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>This rule reports an issue when one of these methods is invoked on a virtual thread.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Thread t = Thread.ofVirtual().unstarted(()->{/* some task */});
      t.setPriority(1); // Noncompliant; virtual threads' priority cannot be changed
      t.setDaemon(false); // Noncompliant; will throw IllegalArgumentException
      t.setDaemon(true); // Noncompliant; redundant
      t.start();
      var threadGroup = t.getThreadGroup(); // Noncompliant; virtual thread groups should not be used
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Thread.run() should not be called directly">
    <div class="paragraph">
      <p>The likely intention of a user calling Thread.run() is to start the execution of code within a new thread.
      This, however, is not what happens when this method is called.</p>
    </div>

    <div class="paragraph">
      <p>The purpose of Thread.run() is to provide a method that users can overwrite to specify the code to be executed.
      The actual thread is then started by calling Thread.start().
      When Thread.run() is called directly, it will be executed as a regular method within the current thread.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      Thread myThread = new Thread(runnable);
      myThread.run(); // Noncompliant, does not start a thread
      ```

      ```java Fix theme={null}
      Thread myThread = new Thread(runnable);
      myThread.start(); // Compliant
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="HostnameVerifier.verify should not always return true">
    <div class="paragraph">
      <p>To prevent URL spoofing, <code>HostnameVerifier.verify() methods should do more than simply return true</code>. Doing so may get you quickly past an exception, but that comes at the cost of opening a security hole in your application.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      SSLContext sslcontext = SSLContext.getInstance( "TLS" );
      sslcontext.init(null, new TrustManager[]{new X509TrustManager() {
      public void checkClientTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {}
      public void checkServerTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {}
      public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; }

      }}, new java.security.SecureRandom());

      Client client = ClientBuilder.newBuilder().sslContext(sslcontext).hostnameVerifier(new HostnameVerifier() {
      @Override
      public boolean verify(String requestedHost, SSLSession remoteServerSession) {
      return true;  // Noncompliant
      }
      }).build();
      ```

      ```java Fix theme={null}
      SSLContext sslcontext = SSLContext.getInstance( "TLSv1.2" );
      sslcontext.init(null, new TrustManager[]{new X509TrustManager() {
      @Override
      public void checkClientTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {}
      @Override
      public void checkServerTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {}
      @Override
      public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; }

      }}, new java.security.SecureRandom());

      Client client = ClientBuilder.newBuilder().sslContext(sslcontext).hostnameVerifier(new HostnameVerifier() {
      @Override
      public boolean verify(String requestedHost, SSLSession remoteServerSession) {
      return requestedHost.equalsIgnoreCase(remoteServerSession.getPeerHost()); // Compliant
      }
      }).build();
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Classes and enums with private members should have a constructor">
    <div class="paragraph">
      <p>Non-abstract classes and enums with non-<code>static, private</code> members should explicitly initialize those members, either in a constructor or with a default value.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      class A { // Noncompliant
      private int field;
      }
      ```

      ```java Fix theme={null}
      class A {
      private int field;

      A(int field) {
      this.field = field;
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Threads should be named">
    <div class="paragraph">
      <p>Naming a thread won’t make it run faster or more reliably, but it will make it easier to deal with if you need to debug the application.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Thread t1 = new Thread(new Runnable() {
      // ...
      };
      t1.start();   // Noncompliant; this thread wasn't named
      ```

      ```java Fix theme={null}
      Thread t1 = new Thread(new Runnable() {
      // ...
      };
      t1.setName("t1");
      t1.start();
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Synchronization should not be done on instances of value-based classes">
    <div class="paragraph">
      <p>In Java, value-based classes are those for which instances are final and immutable, like String, Integer and so on, and their identity relies on their value and not their reference.
      When a variable of one of these types is instantiated, the JVM caches its value, and the variable is just a reference to that value.
      For example, multiple String variables with the same value "Hello world!" will refer to the same cached string literal in memory.</p>
    </div>

    <div class="paragraph">
      <p>The synchronized keyword tells the JVM to only allow the execution of the code contained in the following block to one Thread at a time.
      This mechanism relies on the identity of the object that is being synchronized between threads, to prevent that if object X is locked, it will still be possible to lock another object Y.</p>
    </div>

    <div class="paragraph">
      <p>It means that the JVM will fail to correctly synchronize threads on instances of the aforementioned value-based classes, for instance:</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      // These variables "a" and "b" will effectively reference the same object in memory
      Integer a = 0;
      Integer b = 0;

      // This means that in the following code, the JVM could try to lock and execute
      // on the variable "a" because "b" was notified to be released, as the two Integer variables
      // are the same object to the JVM
      void syncMethod(int x) {
      synchronized (a) {
          if (a == x) {
          // ... do something here
          }
      }
      synchronized (b) {
          if (b == x) {
          // ... do something else
          }
      }
      }
      ```

      ```java Fix theme={null}
      private static final Boolean bLock = Boolean.FALSE;
      private static final Integer iLock = Integer.valueOf(0);
      private static final String sLock = "LOCK";
      private static final List<String> listLock = List.of("a", "b", "c", "d");

      public void doSomething() {

      synchronized(bLock) {  // Noncompliant
        ...
      }
      synchronized(iLock) {  // Noncompliant
        ...
      }
      synchronized(sLock) {  // Noncompliant
        ...
      }
      synchronized(listLock) {  // Noncompliant
        ...
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Thread.sleep should not be used in tests">
    <div class="paragraph">
      <p>In asynchronous testing, the test code is written in a way that allows it to wait for the asynchronous operation to complete before
      continuing with the test.</p>
    </div>

    <div class="paragraph">
      <p>Using Thread.sleep in this case can cause flaky tests, slow test execution, and inaccurate test results.
      It creates brittle tests that can fail unpredictably depending on the environment or load.</p>
    </div>

    <div class="paragraph">
      <p>Use mocks or libraries such as Awaitility instead.
      These tools provide features such as timeouts, assertions, and error handling to make it easier to write and manage asynchronous tests.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @Test
      public void testDoTheThing(){

      MyClass myClass = new MyClass();
      myClass.doTheThing();

      Thread.sleep(500);  // Noncompliant
      // assertions...
      }
      ```

      ```java Fix theme={null}
      @Test
      public void testDoTheThing(){

      MyClass myClass = new MyClass();
      myClass.doTheThing();

      await().atMost(2, Duration.SECONDS).until(didTheThing());  // Compliant
      // assertions...
      }

      private Callable<Boolean> didTheThing() {
      return new Callable<Boolean>() {
      public Boolean call() throws Exception {
        // check the condition that must be fulfilled...
      }
      };
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="The Object.finalize() method should not be called">
    <div class="paragraph">
      <p>Before it reclaims storage from an object that is no longer referenced, the garbage collector calls finalize() on the object.</p>
    </div>

    <div class="paragraph">
      <p>This is a good time to release resources held by the object.</p>
    </div>

    <div class="paragraph">
      <p>Because the general contract is that the finalize method should only be called once per object, calling this method explicitly is misleading and does not respect this contract.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public void dispose() throws Throwable {
      this.finalize();                       // Noncompliant
      }
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="wait should not be called when multiple locks are held">
    <div class="paragraph">
      <p>When two locks are held simultaneously, a <code>wait</code> call only releases one of them. The other will be held until some other thread requests a lock on the awaited object. If no unrelated code tries to lock on that object, then all other threads will be locked out, resulting in a deadlock.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      synchronized (this.mon1) {  // threadB can't enter this block to request this.mon2 lock & release threadA
      synchronized (this.mon2) {
      	this.mon2.wait();  // Noncompliant; threadA is stuck here holding lock on this.mon1
      }
      }
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Reusable resources should be initialized at construction time of Lambda functions">
    <div class="paragraph">
      <p>Resources that can be reused across multiple invocations of the Lambda function should be initialized at construction time. For example in the constructor of the class, or in field initializers. This way, when the same container is reused for multiple function invocations, the existing instance can be reused, along with all resources stored in its fields. It is a good practice to reuse SDK clients and database connections by initializing them at class construction time, to avoid recreating them on every lambda invocation. Failing to do so can lead to performance degradation, and when not closed properly, even out of memory errors.</p>
    </div>

    <div class="paragraph">
      <p>This rule reports an issue when the SDK client or the database connection is initialized locally inside a Lambda function.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class App implements RequestHandler<Object, Object> {
      @Override
      public Object handleRequest(final Object input, final Context context) {
        S3Client s3Client = DependencyFactory.s3Client();
        s3Client.listBuckets();
        // ...
      }
      }
      ```

      ```java Fix theme={null}
      public class App implements RequestHandler<Object, Object> {
      private final S3Client s3Client;

      public App() {
        s3Client = DependencyFactory.s3Client();
      }

      @Override
      public Object handleRequest(final Object input, final Context context) {
        s3Client.listBuckets();
        // ...
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="String.indexOf should be used with correct ranges">
    <div class="paragraph">
      <p>Java 21 adds new String.indexOf methods that accept ranges (beginIndex, to endIndex) rather than just a start index.
      A StringIndexOutOfBounds can be thrown when indicating an invalid range, namely when:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>beginIndex > endIndex (eg: beginIndex and endIndex arguments are mistakenly reversed)</p>
        </li>

        <li>
          <p>beginIndex \< 0 (eg: because the older String.indexOf(what, fromIndex) accepts negative values)</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      String hello = "Hello, world!";
      int index = hello.indexOf('o', 11, 7); // Noncompliant, 11..7 is not a valid range
      ```

      ```java Fix theme={null}
      String hello = "Hello, world!";
      int index = hello.indexOf('o', 7, 11); // Compliant
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Inner class calls to super class methods should be unambiguous">
    <div class="paragraph">
      <p>An inner class that extends another type can call methods from both the outer class and parent type directly, without prepending super. or Outer.this..</p>
    </div>

    <div class="paragraph">
      <p>When both the outer and parent classes contain a method with the same name, the compiler will resolve an unqualified call to the parent type’s implementation.
      The maintainer or a future reader may confuse the method call as calling the outer class’s implementation, even though it really calls the super type’s.</p>
    </div>

    <div class="paragraph">
      <p>To make matters worse, the maintainer sees the outer class’s implementation in the same file as the call in the inner class, while the parent type is often declared in another file.
      The maintainer may not even be aware of the ambiguity present, as they do not see the parent’s implementation.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      public class Parent {
      public void foo() { ... }
      }

      public class Outer {
      public void foo() { ... }

      public class Inner extends Parent {
      public void doSomething() {
        foo();  // Noncompliant, it is not explicit if Outer#foo or Parent#foo is the intended implementation to be called.
        // ...
      }
      }
      }
      ```

      ```java Fix theme={null}
      public class Parent {
      public void foo() { ... }
      }

      public class Outer {
      public void foo() { ... }

      public class Inner extends Parent {
      public void doSomething() {
        super.foo(); // Compliant, it is explicit that Parent#foo is the desired implementation to be called.
        // ...
      }
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title=" XML transformers should be secured ">
    <div class="paragraph">
      <p>An XML External Entity or XSLT External Entity (XXE) vulnerability can occur when a \`javax.xml.transform.Transformer is created without enabling "Secure Processing" or when one is created without disabling resolving of both external DTDs and DTD entities. If that external data is being controlled by an attacker it may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when a Transformer\` is created without either of these settings.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Transformer transformer = TransformerFactory.newInstance().newTransformer();
      transformer.transform(input, result);
      ```

      ```java Fix theme={null}
      TransformerFactory factory = TransformerFactory.newInstance();
      factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
      factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "");

      Transformer transformer = factory.newTransformer();

      transformer.transform(input, result);
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Dont use a type parameter when a wildcard is enough">
    <div class="paragraph">
      <p>There is no need to declare a type parameter when naming a type constraint is not required. Using wildcards makes it easier to read.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      <T extends MyClass> void foo(List<T> list) {  // Noncompliant, T is used only once
      for (MyClass myObj : list) {
      doSomething(myObj);
      }
      }
      ```

      ```java Fix theme={null}
      void foo(List<? extends MyClass> list) {
      for (MyClass myObj : list) {
      doSomething(myObj);
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="JUnit test cases should call super methods">
    <div class="paragraph">
      <p>Overriding a parent class method prevents that method from being called unless an explicit super call is made in the overriding method.
      In some cases, not calling the parent method is fine.
      However, setUp and tearDown provide some shared logic that is called before all test cases.
      This logic may change over the lifetime of your codebase.
      To make sure that your test cases are set up and cleaned up consistently, your overriding implementations of setUp and tearDown should call the parent implementations explicitly.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      public class MyClassTest extends MyAbstractTestCase {

      private MyClass myClass;

      @Override
      protected void setUp() throws Exception {  // Noncompliant
      myClass = new MyClass();
      }
      }
      ```

      ```java Fix theme={null}
      public class MyClassTest extends MyAbstractTestCase {

      private MyClass myClass;

      @Override
      protected void setUp() throws Exception {
      super.setUp();
      myClass = new MyClass();
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Mocking all non-private methods of a class should be avoided">
    <div class="paragraph">
      <p>If you end up mocking every non-private method of a class in order to write tests, it is a strong sign that your test became too complex, or that you misunderstood the way you are supposed to use the mocking mechanism.</p>
    </div>

    <div class="paragraph">
      <p>You should either refactor the test code into multiple units, or consider using the class itself, by either directly instantiating it, or creating a new one inheriting from it, with the expected behavior.</p>
    </div>

    <div class="paragraph">
      <p>This rule reports an issue when every member of a given class are mocked.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @Test
      void test_requiring_MyClass() {
      MyClass myClassMock = mock(MyClass.class); // Noncompliant
      when(myClassMock.f()).thenReturn(1);
      when(myClassMock.g()).thenReturn(2);
      //...
      }

      abstract class MyClass {
      abstract int f();
      abstract int g();
      }
      ```

      ```java Fix theme={null}
      @Test
      void test_requiring_MyClass() {
      MyClass myClass = new MyClassForTest();
      //...
      }

      class MyClassForTest extends MyClass {

      @Override
      int f() {
      return 1;
      }

      @Override
      int g() {
      return 2;
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="AssertJ assertions allMatch and doesNotContains should also test for emptiness">
    <div class="paragraph">
      <p>AssertJ assertions \`allMatch and doesNotContains on an empty list always returns true whatever the content of the predicate. Despite being correct, you should make explicit if you expect an empty list or not, by adding isEmpty()/isNotEmpty() in addition to calling the assertion, or by testing the list’s content further. It will justify the useless predicate to improve clarity or increase the reliability of the test.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when any of the methods listed are used without asserting that the list is empty or not and without testing the content.</p>
    </div>

    <div class="paragraph">
      <p>Targetted methods:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>allMatch</p>
        </li>

        <li>
          <p>allSatisfy</p>
        </li>

        <li>
          <p>doesNotContain</p>
        </li>

        <li>
          <p>doesNotContainSequence</p>
        </li>

        <li>
          <p>doesNotContainSubsequence</p>
        </li>

        <li>
          <p>doesNotContainAnyElementsOf\`</p>
        </li>
      </ul>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      List<String> logs = getLogs();

      assertThat(logs).allMatch(e -> e.contains(“error”)); // Noncompliant, this test pass if logs are empty!
      assertThat(logs).doesNotContain("error"); // Noncompliant, do you expect any log?
      ```

      ```java Fix theme={null}
      List<String> logs = getLogs();

      assertThat(logs).isNotEmpty().allMatch(e -> e.contains(“error”));
      // Or
      assertThat(logs).hasSize(5).allMatch(e -> e.contains(“error”));
      // Or
      assertThat(logs).isEmpty();

      // Despite being redundant, this is also acceptable since it explains why you expect an empty list
      assertThat(logs).doesNotContain("error").isEmpty();
      // or test the content of the list further
      assertThat(logs).contains("warning").doesNotContain("error");
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Application components should not be public">
    <div class="paragraph">
      <p>In Spring applications, application components that expose interfaces should be package protected at most, not <code>public</code>. Such reduced visibility helps ensure that the interface is only accessed through the container and not directly.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      // TODO
      ```

      ```java Fix theme={null}
      // TODO
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="orElseGet should be preferred">
    <div class="paragraph">
      <p>No matter whether the optional value is present or not, \`Optional::orElse's argument will always be executed. This is usually not what the developer intended when the content of the orElse() call has side effects. Even when no side effect is involved, the unnecessary computation of the orElse() clause might be a waste of resources.</p>
    </div>

    <div class="paragraph">
      <p>Calls to <a href="https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html#orElse-T-">Optional::orElse</a> should be replaced with <a href="https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html#orElseGet-java.util.function.Supplier-">Optional::orElseGet</a> whenever the alternative value is not a constant.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when Optional::orElse\` is called with an argument that doesn’t evaluate to a constant value.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Optional<MyObj> opt = getOptMyObj();
      MyObj myObj = opt.orElse(new MyObj());  // Noncompliant
      ```

      ```java Fix theme={null}
      Optional<MyObj> opt = getOptMyObj();
      MyObj myObj = opt.orElseGet(MyObj::new); 
      Optional<String> optString = getOptString();
      String str = opt.orElse("hello");
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Regexes containing characters subject to normalization should use the CANON_EQ flag">
    <div class="paragraph">
      <p>Characters like <code>'é' can be expressed either as a single code point or as a cluster of the letter 'e' and a combining accent mark. Without the CANON\_EQ</code> flag, a regex will only match a string in which the characters are expressed in the same way.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      String s = "e\u0300";
      Pattern p = Pattern.compile("é|ë|è"); // Noncompliant
      System.out.println(p.matcher(s).replaceAll("e")); // print 'è'
      ```

      ```java Fix theme={null}
      String s = "e\u0300";
      Pattern p = Pattern.compile("é|ë|è", Pattern.CANON_EQ);
      System.out.println(p.matcher(s).replaceAll("e")); // print 'e'
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Iterator.hasNext() should not call Iterator.next()">
    <div class="paragraph">
      <p>Calling Iterator.hasNext() is not supposed to have any side effects and hence should not change the iterator’s state. Iterator.next() advances the iterator by one item. So calling it inside Iterator.hasNext() breaks the hasNext() contract and will lead to unexpected behavior in production.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      class MyIterator implements Iterator<Integer> {

      private Queue<Integer> elements;

      ...

      @Override
      public boolean hasNext() {
      try {
        next(); // Noncompliant, next() is called from hasNext()
        return true;
      } catch (NoSuchElementException e) {
        return false;
      }
      }

      @Override
      public Integer next() {
      return elements.remove();
      }
      }
      ```

      ```java Fix theme={null}
      class MyIterator implements Iterator<Integer> {

      private Queue<Integer> elements;

      ...

      @Override
      public boolean hasNext() {
      return !elements.isEmpty(); // Compliant, no call to next()
      }

      @Override
      public Integer next() {
      return elements.remove();
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="collect should be used with Streams instead of list::add">
    <div class="paragraph">
      <p>While you can use either <code>forEach(list::add) or collect with a Stream, collect</code> is by far the better choice because it’s automatically thread-safe and parallellizable.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      List<String> bookNames = new ArrayList<>();
      books.stream().filter(book -> book.getIsbn().startsWith("0"))
                  .map(Book::getTitle)
                  .forEach(bookNames::add);  // Noncompliant
      ```

      ```java Fix theme={null}
      List<String> bookNames = books.stream().filter(book -> book.getIsbn().startsWith("0"))
                  .map(Book::getTitle)
                  .collect(Collectors.toList());
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Constructors should not access uninitialized values">
    <div class="paragraph">
      <p>Constructors should not access the values of fields that haven’t yet been initialized.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public abstract class MyAbstractClass() {

      String name;
      String fname;
      int hashCode;

      public abstract String getValue();

      public MyAbstractClass(String name) {
      this.fname = this.name.split()[0];  // Noncompliant; this.name not assigned yet
      this.hashCode = getValue().hashCode();  // Noncompliant; child class constructor hasn't run yet
      }
      }
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Object.finalize() should remain protected (versus public) when overriding">
    <div class="paragraph">
      <p>The contract of the <code>Object.finalize()</code> method is clear: only the Garbage Collector is supposed to call this method.</p>
    </div>

    <div class="paragraph">
      <p>Making this method public is misleading, because it implies that any caller can use it.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class MyClass {

      @Override
      public void finalize() {    // Noncompliant
      /* ... */
      }
      }
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="getClass should not be used for synchronization">
    <div class="paragraph">
      <p>\`getClass should not be used for synchronization in non-final classes because child classes will synchronize on a different object than the parent or each other, allowing multiple threads into the code block at once, despite the synchronized keyword.</p>
    </div>

    <div class="paragraph">
      <p>Instead, hard code the name of the class on which to synchronize or make the class final\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class MyClass {
      public void doSomethingSynchronized(){
      synchronized (this.getClass()) {  // Noncompliant
        // ...
      }
      }
      ```

      ```java Fix theme={null}
      public class MyClass {
      public void doSomethingSynchronized(){
      synchronized (MyClass.class) {
        // ...
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Expressions used in assert should not produce side effects">
    <div class="paragraph">
      <p>Since <code>assert</code> statements aren’t executed by default (they must be enabled with JVM flags) developers should never rely on their execution the evaluation of any logic required for correct program function.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      assert myList.remove(myList.get(0));  // Noncompliant
      ```

      ```java Fix theme={null}
      boolean removed = myList.remove(myList.get(0));
      assert removed;
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="A for loop update clause should move the counter in the right direction">
    <div class="paragraph">
      <p>A for loop with a counter moving away from the end of the specified range is likely a programming mistake.</p>
    </div>

    <div class="paragraph">
      <p>If the intention is to iterate over the specified range, this differs from what the loop does because the counter moves in the wrong direction.</p>
    </div>

    <div class="paragraph">
      <p>If the intention is to have an infinite loop or a loop terminated only by a break statement, there are two problems:</p>
    </div>

    <div class="olist arabic">
      <ol class="arabic">
        <li>
          <p>The loop condition is not infinite because the counter variable will eventually overflow and fulfill the condition. This can take a long time, depending on the data type of the counter.</p>
        </li>

        <li>
          <p>An infinite loop terminated by a break statement should be implemented using a while or do while loop to make the developer’s intention clear to the reader.</p>
        </li>
      </ol>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      for (int i = 10; i > 0; i++) { // Noncompliant, wrong direction
      System.out.println("Hello, world!") // executed ca. 2 billion times
      }
      ```

      ```java Fix theme={null}
      public void doSomething(String [] strings) {
      for (int i = 0; i < strings.length; i--) { // Noncompliant, wrong direction
      String string = strings[i];  // ArrayIndexOutOfBoundsException when i reaches -1
      // ...
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Track uses of disallowed constructors">
    <div class="paragraph">
      <p>This rule allows banning usage of certain constructors.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      Date birthday;
      birthday = new Date("Sat Sep 27 05:42:21 EDT 1986");  // Noncompliant
      birthday = new Date(528176541000L); // Compliant
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Redundant modifiers should not be used">
    <div class="paragraph">
      <p>The methods declared in an \`interface are public and abstract by default. Any variables are automatically public static final. Finally, class and interface are automatically public static. There is no need to explicitly declare them so.</p>
    </div>

    <div class="paragraph">
      <p>Since annotations are implicitly interfaces, the same holds true for them as well.</p>
    </div>

    <div class="paragraph">
      <p>Similarly, the final modifier is redundant on any method of a final class, private is redundant on the constructor of an Enum, and static is redundant for interface nested into a class or enum\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public interface Vehicle {

      public void go(int speed, Direction direction);  // Noncompliant
      ```

      ```java Fix theme={null}
      public interface Vehicle {

      void go(int speed, Direction direction);
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Exception testing via JUnit @Test annotation should be avoided">
    <div class="paragraph">
      <p>When testing exception via <code>@Test</code> annotation, having additional assertions inside that test method can be problematic because any code after the raised exception will not be executed. It will prevent you to test the state of the program after the raised exception and, at worst, make you misleadingly think that it is executed.</p>
    </div>

    <div class="paragraph">
      <p>You should consider moving any assertions into a separate test method where possible, or using <a href="https://github.com/junit-team/junit4/wiki/Exception-testing#using-assertthrows-method">org.junit.Assert.assertThrows</a> instead.</p>
    </div>

    <div class="paragraph">
      <p>Alternatively, you could use <a href="https://github.com/junit-team/junit4/wiki/Exception-testing#trycatch-idiom">try-catch idiom</a> for JUnit version \< 4.13 or if your project does not support lambdas.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      @Test(expected = IndexOutOfBoundsException.class)
      public void testShouldFail() {
      get();
      // This test pass since execution will never get past this line.
      Assert.assertEquals(0, 1);
      }

      private Object get() {
      throw new IndexOutOfBoundsException();
      }
      ```

      ```java Fix theme={null}
      // This test correctly fails.
      @Test
      public void testToString() {
      Object obj = get();
      Assert.assertThrows(IndexOutOfBoundsException.class, () -> obj.toString());
      Assert.assertEquals(0, 1);
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Consecutive AssertJ assertThat statements should be chained">
    <div class="paragraph">
      <p>AssertJ assertions methods targeting the same object can be chained instead of using multiple \`assertThat. It avoids duplication and increases the clarity of the code.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue when multiples assertThat\` target the same tested value.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      assertThat(someList).hasSize(3);
      assertThat(someList).contains("something");
      ```

      ```java Fix theme={null}
      assertThat(someList)
      .hasSize(3)
      .contains("something");
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="toString() and clone() methods should not return null">
    <div class="paragraph">
      <p>Calling <code>toString() or clone() on an object should always return a string or an object. Returning null</code> instead contravenes the method’s implicit contract.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public String toString () {
      if (this.collection.isEmpty()) {
      return null; // Noncompliant
      } else {
      // ...
      ```

      ```java Fix theme={null}
      public String toString () {
      if (this.collection.isEmpty()) {
      return "";
      } else {
      // ...
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="default clauses should be last">
    <div class="paragraph">
      <p>\`switch can contain a default clause for various reasons: to handle unexpected values, to show that all the cases were properly considered, etc.</p>
    </div>

    <div class="paragraph">
      <p>For readability purposes, to help a developer quickly spot the default behavior of a switch statement, it is recommended to put the default clause at the end of the switch statement.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue if the default clause is not the last one of the switch’s cases.</p>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      switch (param) {
      case 0:
      doSomething();
      break;
      default: // Noncompliant: default clause should be the last one
      error();
      break;
      case 1:
      doSomethingElse();
      break;
      }
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Standard groupings should be used with digit separators">
    <div class="paragraph">
      <p>Java 7 introduced the ability to use a digit separator (<code>\_</code>) to split a literal number into groups of digits for better readability.</p>
    </div>

    <div class="paragraph">
      <p>To ensure that readability is really improved by using digit separators, this rule verifies:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p><strong>Homogeneity</strong></p>

          <div class="ulist">
            <ul>
              <li>
                <p>Except for the left-most group, which can be smaller, all groups in a number should contain the same number of digits. Mixing group sizes is at best confusing for maintainers, and at worst a typographical error that is potentially a bug.</p>
              </li>
            </ul>
          </div>
        </li>

        <li>
          <p><strong>Standardization</strong></p>

          <div class="ulist">
            <ul>
              <li>
                <p>It is also confusing to regroup digits using a size that is not standard. This rule enforce the following standards:</p>

                <div class="ulist">
                  <ul>
                    <li>
                      <p>Decimal numbers should be separated using groups of 3 digits.</p>
                    </li>

                    <li>
                      <p>Hexadecimal numbers should be separated using groups of 2 or 4 digits.</p>
                    </li>

                    <li>
                      <p>Octal and Binary should be separated using groups of 2, 3 or 4 digits.</p>
                    </li>
                  </ul>
                </div>
              </li>
            </ul>
          </div>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>Furthermore, using groups with more than 4 consecutive digits is not allowed because they are difficult for maintainers to read.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      long decimal_int_value     = 1_554_3124L;          // Noncompliant; mixing groups of 3 and 4 digits
      double decimal_float_value = 7_91_87_14.3456d;     // Noncompliant; using groups of 2 instead of 3 digits
      long hexadecimal_value     = 0x8_3A3_248_6E2L;     // Noncompliant; using groups of 3 instead of 2 or 4 digits
      long octal_value           = 0442_03433_13726L;    // Noncompliant; using groups of 5 instead of 2, 3 or 4 digits.
      long binary_value          = 0b01010110_11101010L; // Noncompliant; using groups of 8 instead of 2, 3 or 4 digits.
      ```

      ```java Fix theme={null}
      long decimal_int_value     = 15_543_124L;
      double decimal_float_value = 7_918_714.3456d;
      long hexadecimal_value     = 0x83_A324_86E2L;
      long octal_value           = 04_4203_4331_3726L;
      long binary_value          = 0b0101_0110_1110_1010L;
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Fields in a Serializable class should either be transient or serializable">
    <div class="paragraph">
      <p>By contract, fields in a Serializable class must themselves be either Serializable or transient.
      Even if the class is never explicitly serialized or deserialized, it is not safe to assume that this cannot happen.
      For instance, under load, most J2EE application frameworks flush objects to disk.</p>
    </div>

    <div class="paragraph">
      <p>An object that implements Serializable but contains non-transient, non-serializable data members (and thus violates the contract) could cause application crashes and open the door to attackers.
      In general, a Serializable class is expected to fulfil its contract and not exhibit unexpected behaviour when an instance is serialized.</p>
    </div>

    <div class="paragraph">
      <p>This rule raises an issue on:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>Non-Serializable fields.</p>
        </li>

        <li>
          <p>When a field is assigned a non-Serializable type within the class.</p>
        </li>

        <li>
          <p>Collection fields when they are not private.
          Values that are not serializable could be added to these collections externally.
          Due to type erasure, it cannot be guaranteed that the collection will only contain serializable objects at runtime despite being declared as a collection of serializable types.</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```java Bad theme={null}
      public class Address {
      ...
      }

      public class Person implements Serializable {
      private static final long serialVersionUID = 1905122041950251207L;

      private String name;
      private Address address;  // Noncompliant, Address is not serializable
      }
      ```

      ```java Fix theme={null}
      public class Address implements Serializable {
      private static final long serialVersionUID = 2405172041950251807L;

      ...
      }

      public class Person implements Serializable {
      private static final long serialVersionUID = 1905122041950251207L;

      private String name;
      private Address address; // Compliant, Address is serializable
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Regex patterns and their sub-patterns should not always fail">
    <div class="paragraph">
      <p>Using certain features of regular expressions, it is possible to create regular expressions that can never match or contain subpatterns that can never match. Since a pattern or sub-pattern that can never match any input is pointless, this is a sign that the pattern does not work as intended and needs to be fixed.</p>
    </div>

    <div class="paragraph">
      <p>This rule finds some such regular expressions and subpatterns, specifically ones that meet one of the following conditions:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>Beginning- and end-of-line/input boundaries appearing in a position where they can never match (e.g. an end-of-input marker being followed by other characters)</p>
        </li>

        <li>
          <p>A back reference refers to a capturing group that will never be matched before the back reference</p>
        </li>
      </ul>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      $[a-z]*^
      ```

      ```java Fix theme={null}
      \1(.)
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Serializable classes should have a serialVersionUID">
    <div class="paragraph">
      <p>A \`serialVersionUID field is strongly recommended in all Serializable classes. If you do not provide one, one will be calculated for you by the compiler. The danger in not explicitly choosing the value is that when the class changes, the compiler will generate an entirely new id, and you will be suddenly unable to deserialize (read from file) objects that were serialized with the previous version of the class.</p>
    </div>

    <div class="paragraph">
      <p>serialVersionUID's should be declared with all of these modifiers: static final long\`.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public class Raspberry extends Fruit  // Noncompliant; no serialVersionUID. 
          implements Serializable {
      private String variety;

      public Raspberry(Season ripe, String variety) { ...}
      public void setVariety(String variety) {...}
      public String getVarity() {...}
      }

      public class Raspberry extends Fruit
          implements Serializable {
      private final int serialVersionUID = 1; // Noncompliant; not static & int rather than long
      ```

      ```java Fix theme={null}
      public class Raspberry extends Fruit
          implements Serializable {
      private static final long serialVersionUID = 1;
      private String variety;

      public Raspberry(Season ripe, String variety) { ...}
      public void setVariety(String variety) {...}
      public String getVarity() {...}
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Constructors of an abstract class should not be declared public">
    <div class="paragraph">
      <p>Abstract classes should not have public constructors. Constructors of abstract classes can only be called in constructors of their subclasses. So there is no point in making them public. The <code>protected</code> modifier should be enough.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      public abstract class AbstractClass1 {
      public AbstractClass1 () { // Noncompliant, has public modifier
          // do something here
      }
      }
      ```

      ```java Fix theme={null}
      public abstract class AbstractClass2 {
      protected AbstractClass2 () {
          // do something here
      }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Conditional Operator using boolean literal can be simplified">
    <div class="paragraph">
      <p>A conditional operator is sometimes cluttering readability, if one of the operand is a boolean literal it can be simplified in a boolean expression :</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      boolean a = condition || exp;
      boolean a = !condition && exp;
      boolean a = !condition ||  exp;
      boolean a = condition && exp;
      ```

      ```java Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Classes that override clone should be Cloneable">
    <div class="paragraph">
      <p><code>Cloneable is the marker Interface that indicates that clone() may be called on an object. Overriding clone() without implementing Cloneable</code> can be useful if you want to control how subclasses clone themselves, but otherwise, it’s probably a mistake.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      class Team  {  // Noncompliant
      private Person coach;
      private List<Person> players;
      public void addPlayer(Person p) { ... }
      public Person getCoach() { ... }

      @Override
      public Team clone() { ... }
      }
      ```

      ```java Fix theme={null}
      class Team implements Cloneable {
      private Person coach;
      private List<Person> players;
      public void addPlayer(Person p) { ... }
      public Person getCoach() { ... }

      @Override
      public Team clone() { ... }
      }
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Format strings should use the correct symbols">
    <div class="paragraph">
      <p>Different formatters use different formatting symbols, and it can be easy to confuse one for the other. But get it wrong, and your output may be useless.</p>
    </div>

    <div class="paragraph">
      <p>This rule logs an issue when the wrong type of format string is used for Guava, slf4j, logback or <code>MessageFormat</code> strings.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```java Bad theme={null}
      String message = MessageFormat.format("Now is the %s %d all good people", "time", 4);  // Noncompliant
      ```

      ```java Fix theme={null}
      String message = MessageFormat.format("Now is the {1} {2} all good people", "time", 4);  // Noncompliant
      ```
    </CodeGroup>
  </Accordion>
</AccordionGroup>