Java - 2

Since Java 7, `Strings can be used as switch arguments. So when a single String is tested against three or more values in an if/else if structure, it should be converted to a switch instead for greater readability.

Note that this rule is automatically disabled when the project’s sonar.java.source is lower than 7`.

Comparisons of dissimilar types will always return false. The comparison and all its dependent code can simply be removed. This includes:

Specifically in the case of arrays, since arrays don’t override Object.equals(), calling equals on two arrays is the same as comparing their addresses. This means that array1.equals(array2) is equivalent to array1==array2.

However, some developers might expect Array.equals(Object obj) to do more than a simple memory address comparison, comparing for instance the size and content of the two arrays. Instead, the == operator or Arrays.equals(array1, array2)` should always be used with arrays.

Using a type parameter when you don’t have to simply obfuscates the code. Qualifying an inner type with a type parameter will compile, but confuse maintainers.

This rule allows you to track the use of the Checkstyle suppression comment mechanism.

HttpSession s are managed by web servers and can be serialized and stored on disk as the server manages its memory use in a process called “passivation” (and later restored during “activation”).

Even though HttpSession does not extend Serializable, you must nonetheless assume that it will be serialized. If non-serializable objects are stored in the session, serialization might fail.

A cache is a long-lived object that holds references to shorter-lived objects. To prevent a cache from growing indefinitely, old objects the cache should be removed when they’re no longer used. This can be done with the use of soft references, which allow the garbage collector to remove unused cache entries when memory needs to be freed.

This rule raises an issue when a `static collection does not use SoftReference.

Note that this rule is automatically disabled when the project’s sonar.java.source` is lower than 7.

The Object#equals(Object obj) method is used to compare two objects to see if they are equal.

The obj parameter’s type is Object, this means that an object of any type can be passed as a parameter to this method.

Any class overriding Object#equals(Object obj) should respect this contract, accept any object as an argument, and return false when the argument’s type differs from the expected type. The obj parameter’s type can be checked using instanceof or by comparing the getClass() value:

The readObject method is implemented when a Serializable object requires special handling to be reconstructed from a file. The object created by readObject is accessed only by the thread that called the method, thus using the synchronized keyword in this context is unnecessary and causes confusion.

In Java 8, underscore (_) cannot be used as a parameter to a lambda, and by Java 9, it’s a keyword. To ensure future portability (not to mention current readability), it should not be used now as an identifier.

According to the Java `Comparable.compareTo(T o) documentation:

notify and notifyAll both wake up sleeping threads waiting on the object’s monitor, but notify only wakes up one single thread, while notifyAll wakes them all up. Unless you do not care which specific thread is woken up, notifyAll should be used instead.

The `java.util.function package provides a large array of functional interface definitions for use in lambda expressions and method references. In general it is recommended to use the more specialised form to avoid auto-boxing. For instance IntFunction<Foo> should be preferred over Function<Integer, Foo>.

This rule raises an issue when any of the following substitution is possible:

By accepting persistent entities as method arguments, the application allows clients to manipulate the object’s properties directly.

Validation is the first line of defense against injection, cross-site scripting, and many other attacks. Omitting it in modern web applications is simply negligent.

When creating a Struts ActionForm, you have the choice of extending something from the org.apache.struts.action package, or extending something from the org.apache.struts.validator package. Since you can’t use the Struts validator capabilities without extending something from the validator package, that should always be your choice.

If you go to the trouble of importing a symbol statically, then you should make use of it, and you should do so consistently. Similarly, there’s no reason to both import a class and then refer to it in code by its fully-qualified name. Otherwise, maintainers could be confused by the difference between qualified and unqualified references.

By contract, the NullCipher class provides an “identity cipher” - one that does not transform or encrypt the plaintext in any way. As a consequence, the ciphertext is identical to the plaintext. So this class should be used for testing, and never in production code.

Both `FixedSizeList from the Commons library, and the list returned from Arrays.asList offer add and remove methods (as required by the List interface they implement), but neither truly supports their use. Both list types have fixed lengths and will throw errors if an add or remove method, or any of their variations, is called.

This rule raises an issue when one of the following methods is invoked on a FixedSizeList instance:

When verifying that code raises a runtime exception, a good practice is to avoid having multiple method calls inside the tested code, to be explicit about which method call is expected to raise the exception.

It increases the clarity of the test, and avoid incorrect testing when another method is actually raising the exception.

Fields marked as transient in a Serializable class will be ignored during serialization and consequently not written out to a file (or stream).

This can be useful in situations such as where the content of a field can be recomputed from other fields. To reduce the output size, this field can be marked as transient and recomputed when a given object is deserialized.

Since transient is very specific to classes that implement Serializable, it is superfluous in classes that do not.

This rule raises an issue when a field is marked as transient, even though the containing class does not implement Serializable.

If you’ve gone to the trouble of writing an iterator method in a class that doesn’t implement Iterable, that trivial omission is costing you half the benefit of the method because you can’t use the class in enhanced for loops.

A Spring `singleton bean may be used by many threads at once, and the use of instance (non-static) variables could cause concurrency issues.

This rule applies to classes with the following annotations: @Service, @Component, @Repository, @Scope(“singleton”)`

Using boxed values in a ternary operator does not simply return one operand or the other based on the condition. Instead, the values are unboxed and coerced to a common type, which can result in a loss of precision when converting one operand from int to float or from long to double.

While this behavior is expected for arithmetic operations, it may be unexpected for the ternary operator. To avoid confusion or unexpected behavior, cast to a compatible type explicitly.

Once a value is known to be null or non-null, there’s no reason to re-check it unless it has been changed (or potentially changed) in the interim. Doing so anyway may may just be an over-abundance of caution, but it could indicate a bug.

There’s no valid reason to test this with instanceof. The only plausible explanation for such a test is that you’re executing code in a parent class conditionally based on the kind of child class this is. But code that’s specific to a child class should be in that child class, not in the parent.

The old, much-derided Date and Calendar classes have always been confusing and difficult to use properly, particularly in a multi-threaded context. JodaTime has long been a popular alternative, but now an even better option is built-in. Java 8’s JSR 310 implementation offers specific classes for:

A for loop termination condition should test the loop counter against an invariant value that does not change during the execution of the loop. Invariant termination conditions make the program logic easier to understand and maintain.

This rule tracks three types of non-invariant termination conditions:

Even if it is technically possible, Restricted Identifiers should not be used as identifiers. This is only possible for compatibility reasons, using it in Java code is confusing and should be avoided.

Note that this applies to any version of Java, including the one where these identifiers are not yet restricted, to avoid future confusion.

This rule reports an issue when restricted identifiers:

are used as identifiers.

Collection.removeIf is more readable and less verbose than using the Iterator.remove idiom. It might also be more performant in some cases, particularly for ArrayList instances.

If the Service Provider does not manage to properly validate the incoming SAML response message signatures, attackers might be able to manipulate the response content without the application noticing. Especially, they might be able to alter the authentication-targeted user.

JDK7 introduced the class `java.nio.charset.StandardCharsets. It provides constants for all charsets that are guaranteed to be available on every implementation of the Java platform.

These constants should be preferred to:

The processHttpRequest method and methods called from it can be executed by multiple threads within the same servlet instance, and state changes to the instance caused by these methods are, therefore, not threadsafe.

This is due to the servlet container creating only one instance of each servlet (javax.servlet.http.HttpServlet) and attaching a dedicated thread to each incoming HTTP request. The same problem exists for org.apache.struts.action.Action but with different methods.

To prevent unexpected behavior, avoiding mutable states in servlets is recommended. Mutable instance fields should either be refactored into local variables or made immutable by declaring them final.

In Switch Expressions, an arrow label consisting of a block with a single `yield can be simplified to directly return the value, resulting in cleaner code.

Similarly, for Switch Statements and arrow labels, a break in a block is always redundant and should not be used. Furthermore, if the resulting block contains only one statement, the curly braces of that block can also be omitted.

This rule reports an issue when a case of a Switch Expression contains a block with a single yield or when a Switch Statement contains a block with a break`.

In a multi-threaded situation, un-`synchronized lazy initialization of static fields could mean that a second thread has access to a half-initialized object while the first thread is still creating it. Allowing such access could cause serious bugs. Instead. the initialization block should be synchronized.

Similarly, updates of such fields should also be synchronized.

This rule raises an issue whenever a lazy static initialization is done on a class with at least one synchronized` method, indicating intended usage in multi-threaded applications.

There’s no need to null-test a variable before an instanceof test because instanceof tests for null. Similarly, there’s no need to null-test a variable before dereferencing some other object.

Denoted by the ”@” symbol, annotations are metadata that can be added to classes, methods, and variables for various purposes such as documentation, code analysis, and runtime processing.

Annotations have retention policies that determine in which context they are retained and available for use. There are three retention policies for annotations:

It is important to understand that only annotations having the RUNTIME retention policy can be accessed at runtime using reflection. For example, the following if condition is true when the method argument is the java.util.function.Function class:

Before Java 8, a container annotation was required as wrapper to use multiple instances of the same annotation. As of Java 8, this is no longer necessary. Instead, these annotations should be used directly without a wrapper, resulting in cleaner and more readable code.

This rule is automatically disabled when the project’s sonar.java.source is lower than 8 as repeating annotations were introduced in Java 8.

Java 21 virtual threads allow the JVM to optimize the usage of OS threads, by mounting and unmounting them on an OS thread when needed, and making them more efficient when dealing with blocking operations such as HTTP requests or I/O.

However, when code is executed inside a synchronized block or synchronized method, the virtual thread stays pinned to the underlying OS thread and cannot be unmounted during a blocking operation. This will cause the OS thread to be blocked, which can impact the scalability of the application.

Therefore, virtual threads should not execute code that contains synchronized blocks or invokes synchronized methods. Platform threads should be used in these cases.

This rule raises an issue when a virtual thread contains synchronized blocks or invokes synchronized methods.

According to the Java documentation, any implementation of the `InputSteam.read() method is supposed to read the next byte of data from the input stream. The value byte must be an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned.

But in Java, the byte primitive data type is an 8-bit signed two’s complement integer. It has a minimum value of -128 and a maximum value of 127. So by contract, the implementation of an InputSteam.read() method should never directly return a byte` primitive data type. A conversion into an unsigned byte must be done before by applying a bitmask.

Setting the wrong Content-Type for a response can leave an application vulnerable to cross-site scripting attacks. Specifically, JSON should always be served with the `application/json Content-Type.

This rule checks the Content-Type of responses containing classes in the org.json and javax.json` packages.

Hibernate’s lazy loading allows you to retrieve just the data of the current class without being forced to load all its related classes. For instance with lazy loading, you can pull up an instance of a `Lecture @Entity without being forced to load all its Students.

But that’s only if you’re storing the Students in a collection. Store them in an array instead, and the benefits of lazy loading are no longer available.

This rule raises an issue on each array in @Entity` classes.

Configured URL matchers are considered in the order they are declared. Especially, for a given resource, if a looser filter is defined before a stricter one, only the less secure configuration will apply. No request will ever reach the stricter rule.

This rule raises an issue when:

`ThreadLocal variables are supposed to be garbage collected once the holding thread is no longer alive. Memory leaks can occur when holding threads are re-used which is the case on application servers using pool of threads.

To avoid such problems, it is recommended to always clean up ThreadLocal variables using the remove() method to remove the current thread’s value for the ThreadLocal variable.

In addition, calling set(null) to remove the value might keep the reference to this pointer in the map, which can cause memory leak in some scenarios. Using remove` is safer to avoid this issue.

Shared naming conventions allow teams to collaborate efficiently.

This rule raises an issue when a method name does not match a provided regular expression.

For example, with the default provided regular expression ^[a-z][a-zA-Z0-9]*$, the method:

The Reader.read() and the BufferedReader.readLine() are used for reading data from a data source. The return value of these methods is the data read from the data source, or null when the end of the data source is reached. If the return value is ignored, the data read from the source is thrown away and may indicate a bug.

This rule raises an issue when the return values of Reader.read() and BufferedReader.readLine() and their subclasses are ignored or merely null-checked.

Unlike similar AssertJ methods testing exceptions (`assertThatCode(), assertThatExceptionOfType(), …​), the assertThatThrownBy() method can be used alone, failing if the code did not raise any exception.

Still, only testing that an exception was raised is not enough to guarantee that it was the expected one, and you should test the exception type or content further. In addition, it will make explicit what you are expecting, without relying on side-effects.

This rule raises an issue when assertThatThrownBy` is used, without testing the exception further.

JUnit assertions should not be made from the run method of a Runnable, because their failure may not be detected in the test that initiated them. Failed assertions throw assertion errors. However, if the error is thrown from another thread than the one that initiated the test, the thread will exit but the test will not fail.

Having too many return statements in a method increases the method’s essential complexity because the flow of execution is broken each time a return statement is encountered. This makes it harder to read and understand the logic of the method.

Java 7’s try-with-resources structure automatically handles closing the resources that the try itself opens. Thus, adding an explicit close() call is redundant and potentially confusing.

In records, introduced in Java 16, there are 2 ways to write a custom constructor: canonical and compact.

A canonical constructor is an ordinary constructor with arguments for all private fields. The default implementation just provides initialization for all private fields and there is no need to write it manually. You might want to write it yourself when you need to customize the constructor logic.

A compact constructor doesn’t have parameters defined explicitly, parentheses are omitted and access to private fields is not possible (even via this). The compact constructor has access to the constructor’s arguments and its body is executed right before the field initialization. It’s a perfect place to provide validation.

This rule reports an issue when a canonical constructor can be easily replaced by a compact version when these requirements are met:

The repetition of a unary operator is usually a typo. The second operator invalidates the first one in most cases:

Non final classes shouldn’t use a hardcoded class name in the equals method. Doing so breaks the method for subclasses. Instead, make the comparison dynamic.

In Records, serialization is not done the same way as for ordinary serializable or externalizable classes. The serialized representation of a record object will be a sequence of values (record components). During the deserialization of records, the stream of components is read and components are constructed. Then the record object is recreated by invoking the record’s canonical constructor with the component values serving as arguments (or default values for absent arguments).

This process cannot be customized, so any class-specific `writeObject, readObject, readObjectNoData, writeExternal, and readExternal methods or serialPersistentFields fields in record classes are ignored during serialization and deserialization.

However, there is a way to substitute serialized/deserialized objects in writeReplace and readResolve.

This rule raises an issue when any of writeObject, readObject, readObjectNoData, writeExternal, readExternal or serialPersistentFields` are present as members in a Record class.

Java 21 introduces case null for switch. It is a more concise and readable way to handle nullability compared to an if statement before a switch.

When the application does not implement controls over the JMS object types, its clients could be able to force the deserialization of arbitrary objects. This may lead to deserialization injection attacks.

StringBuffer and StringBuilder instances that are appended but never toStringed needlessly clutter the code, and worse are a drag on performance. Either they should be removed, or the missing toString call added.

When using the `Stream API, call chains should be simplified as much as possible. Not only does it make the code easier to read, it also avoid creating unnecessary temporary objects.

This rule raises an issue when one of the following substitution is possible:

java.lang.Error and its subclasses represent abnormal conditions, such as OutOfMemoryError, which should only be encountered by the Java Virtual Machine.

A common reason for a poorly performant query is because it’s processing more data than required.

Querying unnecessary data demands extra work on the server, adds network overhead, and consumes memory and CPU resources on the application server. The effect is amplified when the query includes multiple joins.

The rule flags an issue when a SELECT * query is provided as an argument to methods in java.sql.Connection and java.sql.Statement.

Objects annotated with Mockito annotations `@Mock, @Spy, @Captor, or @InjectMocks need to be initialized explicitly.

There are several ways to do this:

Test using uninitialized mocks will fail.

Note that this only applies to annotated Mockito objects. It is not necessary to initialize objects instantiated via Mockito.mock() or Mockito.spy()`.

This rule raises an issue when a test class uses uninitialized mocks.

Some mathematical operations are unnecessary and should not be performed because their results are predictable.

For instance, anyValue % 1 will always return 0, as any integer value can be divided by 1 without remainder.

Similarly, casting a non-floating-point to a floating-point value and then passing it to Math.round, Math.ceil, or Math.floor is also unnecessary, as the result will always be the original value.

The following operations are unnecessary when given any constant value: Math.abs, Math.ceil, Math.floor, Math.rint, Math.round. Instead, use the result of the operation directly.

The following operations are unnecessary with certain constants and can be replaced by the result of the operation directly:

The Spring framework’s @RestController annotation is equivalent to using the @Controller and @ResponseBody annotations together. As such, it is redundant to add a @ResponseBody annotation when the class is already annotated with @RestController.

Passing single null or primitive array argument to the variable arity method may not work as expected. In the case of null, it is not passed as array with single element, but the argument itself is null. In the case of a primitive array, if the formal parameter is Object…, it is passed as a single element array. This may not be obvious to someone not familiar with such corner cases, and it is probably better to avoid such ambiguities by explicitly casting the argument to the desired type.

@VisibleForTesting can be used to mark methods, fields and classes whose visibility restrictions have been relaxed more than necessary for the API to allow for easier unit testing.

Access to such methods, fields and classes only possible thanks to this relaxed visibility is fine for test code, but it should be avoided in production code. In production code these methods should be treated as if they are private.

Supported framework:

or any other annotation named VisibleForTesting`

Java 15 introduced feature of `sealed classes. With sealed classes and interfaces you can specify a strict hierarchy of types and restrict possible inheritance.

Although this feature can help to make code safer, it is not applicable everywhere. Functional interfaces can not be sealed. This means that if an interface with a single abstract method is declared with a sealed keyword, its implementation can’t be replaced with a lambda.

This rule reports an issue when an interface with a single abstract method is marked sealed`.

When List.remove() is called, the list shrinks, and the indices of all elements following the removed element are decremented by one. If this operation is performed within a loop that iterates through the elements in ascending order, it will cause the loop to skip the element immediately following the removed element.

According to the EJB specification, EJB’s:

This rule raises an issue each time an EJB obtains a class loader.

Overriding a parent class’ method implementation with an `abstract method is a terrible practice for a number of reasons:

In Java, the Thread class represents a thread of execution. Synchronization between threads is typically achieved using objects or shared resources.

The methods wait(…​), notify(), and notifyAll() are related to the underlying object’s monitor and are designed to be called on objects that act as locks or monitors for synchronization. These methods are available on Java Object and, therefore, automatically inherited by all objects, including Thread.

Calling these methods on a Thread may corrupt the behavior of the JVM, which relies on them to change the state of the thread (BLOCKED, WAITING,…​).

An equals method that unconditionally returns the same answer is an error likely to cause many bugs.

When using null-related annotations at global scope level, for instance using `javax.annotation.ParametersAreNonnullByDefault (from JSR-305) at package level, it means that all the parameters to all the methods included in the package will, or should, be considered Non-null. It is equivalent to annotating every parameter in every method with non-null annotations (such as @Nonnull).

The rule raises an issue every time a parameter could be null` for a method invocation, where the method is annotated as forbidding null parameters.

Calling an overridable method from a constructor could result in failures or strange behaviors when instantiating a subclass which overrides the method.

For example:

`Optional value can hold either a value or not. The value held in the Optional can be accessed using the get() method, but it will throw a

NoSuchElementException if there is no value present. To avoid the exception, calling the isPresent() or ! isEmpty() method should always be done before any call to get().

Alternatively, note that other methods such as orElse(…), orElseGet(…) or orElseThrow(…) can be used to specify what to do with an empty Optional`.

Throwing generic exceptions such as `Error, RuntimeException, Throwable, and Exception will have a negative impact on any code trying to catch these exceptions.

From a consumer perspective, it is generally a best practice to only catch exceptions you intend to handle. Other exceptions should ideally be let to propagate up the stack trace so that they can be dealt with appropriately. When a generic exception is thrown, it forces consumers to catch exceptions they do not intend to handle, which they then have to re-throw.

Besides, when working with a generic type of exception, the only way to distinguish between multiple exceptions is to check their message, which is error-prone and difficult to maintain. Legitimate exceptions may be unintentionally silenced and errors may be hidden.

For instance, when a Throwable is caught and not re-thrown, it may mask errors such as OutOfMemoryError` and prevent the program from terminating gracefully.

When throwing an exception, it is therefore recommended to throw the most specific exception possible so that it can be handled intentionally by consumers.

Well-named functions can allow the users of your code to understand at a glance what to expect from the function - even before reading the documentation. Toward that end, methods returning a boolean should have names that start with “is” or “has” rather than with “get”.

The ability to map a class to a database table has made database interaction in Java a lot easier. But map multiple classes to the same table and you’ll end up with a classic case of the left hand not knowing what the right hand is doing. In the worse case scenario, it could lead to serious data corruption.

This rule raises an issue when multiple classes are mapped to the same table with Hibernate or JPA annotations.

When using POSIX classes like `\p{Alpha} without the UNICODE_CHARACTER_CLASS flag or when using hard-coded character classes like “[a-zA-Z]”, letters outside of the ASCII range, such as umlauts, accented letters or letter from non-Latin languages, won’t be matched. This may cause code to incorrectly handle input containing such letters.

To correctly handle non-ASCII input, it is recommended to use Unicode classes like \p{IsAlphabetic}. When using POSIX classes, Unicode support should be enabled by either passing Pattern.UNICODE_CHARACTER_CLASS as a flag to Pattern.compile or by using (?U)` inside the regex.

Testing equality or nullness with JUnit’s assertTrue() or assertFalse() should be simplified to the corresponding dedicated assertion.

Using `File.createTempFile as the first step in creating a temporary directory causes a race condition and is inherently unreliable and insecure. Instead, Files.createTempDirectory (Java 7+) or a library function such as Guava’s similarly-named Files.createTempDir should be used.

This rule raises an issue when the following steps are taken in immediate sequence:

Note that this rule is automatically disabled when the project’s sonar.java.source is lower than 7`.

It is not uncommon, for instance when dealing with SQL requests, to have repeated calls to StringBuilder.append() to create a long (sometimes really long) String that will be then passed to the appropriate subsystem (e.g. jdbc.Statement()). This is very undesirable because it makes it more difficult to read, and maintain, the statement in the String due to overlapping syntaxes.

It is highly recommended to address such a case with an external text file loaded as a resource.

The purpose of the @Value annotation in org.springframework.beans.factory.annotation is to inject a value into a field or method based on the Spring context after it has been established.

If the annotation does not include an expression (either Spring Expression Language or a property injection), the injected value is a simple constant that does not depend on the Spring context, making the annotation replaceable with a standard field initialization statement.

This not only implies the redundant use of @Value, but could also indicate an error where the expression indicators (#, $) were omitted by mistake.

For maximum reusability, methods should accept parameters with as little specialization as possible. So unless specific features from a child class are required by a method, a type higher up the class hierarchy should be used instead.

Because printf-style format strings are interpreted at runtime, rather than validated by the Java compiler, they can contain errors that lead to unexpected behavior or runtime errors. This rule statically validates the good behavior of printf-style formats when calling the format(…) methods of java.util.Formatter, java.lang.String, java.io.PrintStream, MessageFormat, and java.io.PrintWriter classes and the printf(…) methods of java.io.PrintStream or java.io.PrintWriter classes.

ThreadPoolExecutor is an object that efficiently manages and controls the execution of multiple tasks in a thread pool. A thread pool is a collection of pre-initialized threads ready to execute tasks. Instead of creating a new thread for each task, which can be costly in terms of system resources, a thread pool reuses existing threads.

java.util.concurrent.ScheduledThreadPoolExecutor is an extension of ThreadPoolExecutor that can additionally schedule commands to run after a given delay or to execute periodically.

ScheduledThreadPoolExecutor ‘s pool is sized with corePoolSize, so setting corePoolSize to zero means the executor will have no threads and run nothing. corePoolSize should have a value greater than zero and valid for your tasks.

This rule detects instances where corePoolSize is set to zero via its setter or the object constructor.

The request handler function in a Controller should set the appropriate HTTP status code based on the operation’s success or failure. This is done by returning a Response object with the appropriate status code.

If an exception is thrown during the execution of the handler, the status code should be in the range of 4xx or 5xx. Examples of such codes are BAD_REQUEST, UNAUTHORIZED, FORBIDDEN, NOT_FOUND, INTERNAL_SERVER_ERROR, BAD_GATEWAY, SERVICE_UNAVAILABLE, etc.

The status code should be 1xx, 2xx, or 3xx if no exception is thrown and the operation is considered successful. Such codes include OK, CREATED, MOVED_PERMANENTLY, FOUND, etc.

Java offers a built-in serialization mechanism for classes that implement the Serializable interface. The developer can either rely on Java’s default serialization and deserialization logic or implement custom methods for these tasks. The JVM will use methods such as readObject and writeObject to execute custom behavior. This only works, however, if these methods match exactly the expected signatures. If they do not, the JVM will fall back to the default logic, resulting in unexpected behavior at runtime, while the developer believes that the default logic has been overidden.

This rule raises an issue if an implementation of writeObject, readObject, readObjectNoData, writeReplace, or readResolve has an incorrect access modifier, return type, or is not static when it should be (and vice-versa).

In certain Android methods, calls to the `super version of the method should always come first. Otherwise, you risk leaving the job half-done.

This rule raises an issue when the following Activity methods do not begin with a call to super:

Classes annotated as @Controller in Spring are responsible for handling incoming web requests. When annotating methods or the entire controller with @ResponseBody, the return value of said methods will be serialized and set as the response body. In other words, it tells the Spring framework that this method does not produce a view. This mechanism is commonly used to create API endpoints.

Spring provides @RestController as a convenient annotation to replace the combination of @Controller and @ResponseBody. The two are functionally identical, so the single annotation approach is preferred.

This rule will raise an issue on a class that is annotated with @Controller if:

Calling System.exit(int status) or Rutime.getRuntime().exit(int status) calls the shutdown hooks and shuts downs the entire Java virtual machine. Calling Runtime.getRuntime().halt(int) does an immediate shutdown, without calling the shutdown hooks, and skipping finalization.

Each of these methods should be used with extreme care, and only when the intent is to stop the whole Java process. For instance, none of them should be called from applications running in a J2EE container.

This rule is not really a rule, but a demonstration of the features from Asciidoc that can appear in a rule description.

More specifically, its “How to fix it” section contains several frameworks.

By default case insensitivity only affects letters in the ASCII range. This can be changed by either passing Pattern.UNICODE_CASE or Pattern.UNICODE_CHARACTER_CLASS as an argument to Pattern.compile or using (?u) or (?U) within the regex.

If not done, regular expressions involving non-ASCII letters will still handle those letters as being case sensitive.

Most checks against an indexOf value compare it with -1 because 0 is a valid index. Checking against > 0 ignores the first element, which is likely a bug.

Generic types (types with type parameters) have been introduced into Java with language version 1.5. If type parameters are specified for a class or method, it is still possible to ignore them to keep backward compatibility with older code, which is called the raw type of the class or interface.

Using raw type expressions is highly discouraged because the compiler cannot perform static type checking on them. This means that the compiler will not report typing errors about them at compile time, but a ClassCastException will be thrown during runtime.

In Java 1.5, generics were also added to the Java collections API, and the data structures in java.util, such as List, Set, or Map, now feature type parameters. Collections.EMPTY_LIST, Collections.EMPTY_SET, and Collections.EMPTY_MAP are relics from before generics, and they return raw lists, sets, or maps, with the limitations mentioned above.

Iterating over a collection using a for-each loop in Java relies on iterators.

An iterator is an object that allows you to traverse a collection of elements, such as a list or a dictionary. Iterators are used in for-each loops to iterate over the elements of a collection one at a time.

It is important to note that iterators are designed to be read-only. Modifying a collection while iterating over it can cause unexpected behavior, as the iterator may skip over or repeat elements. Therefore, it is important to avoid modifying a collection while iterating over it to ensure that your code behaves as expected.

Most JDK collection implementations don’t support such modification and may throw a ConcurrentModificationException. Even if no such exception is thrown, attempting to modify a collection during iteration could be the source of incorrect or unspecified behaviors in the code.

If you still want to modify the collection, it is best to refactor the code and use a second collection (e.g by using streams and filter operations).

The BigDecimal is used to represents immutable, arbitrary-precision signed decimal numbers.

Differently from the BigDecimal, the double primitive type and the Double type have limited precision due to the use of double-precision 64-bit IEEE 754 floating point. Because of floating point imprecision, the BigDecimal(double) constructor can be somewhat unpredictable.

For example writing new BigDecimal(0.1) doesn’t create a BigDecimal which is exactly equal to 0.1, but it is equal to 0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length).

Primitives can be read and written to atomically. Except for `long and double, that is. These 64-bit primitives must be marked volatile in multi-threaded environments, or swapped out for their atomic counterparts: AtomicLong, and AtomicDouble to guarantee that their updates are always visible to other threads.

Similarly, to ensure that updates to 32-bit primitives are visible to all threads, they should also be marked volatile`.

In regular expressions the escape sequence `\cX, where the X stands for any character that’s either @, any capital ASCII letter, [, , ], ^ or _, represents the control character that “corresponds” to the character following \c, meaning the control character that comes 64 bytes before the given character in the ASCII encoding.

In some other regex engines (for example in that of Perl) this escape sequence is case insensitive and \cd produces the same control character as \cD. Further using \c with a character that’s neither @, any ASCII letter, [, , ], ^ nor _, will produce a warning or error in those engines. Neither of these things is true in Java, where the value of the character is always XORed with 64 without checking that this operation makes sense. Since this won’t lead to a sensible result for characters that are outside of the @ to _ range, using \c` with such characters is almost certainly a mistake.

This rule raises an issue when:

The battery life is a major concern for mobile devices and choosing the right Sensor is very important to reduce the power usage and extend the battery life.

It is recommended, for reducing the power usage, to use TYPE_GEOMAGNETIC_ROTATION_VECTOR for background tasks, long-running tasks and other tasks not requiring accurate motion detection.

The rule reports an issue when android.hardware.SensorManager#getDefaultSensor uses TYPE_ROTATION_VECTOR instead of TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Spring beans belonging to packages that are not included in a `@ComponentScan configuration will not be accessible in the Spring Application Context. Therefore, it’s likely to be a configuration mistake that will be detected by this rule.

Note: the @ComponentScan is implicit in the @SpringBootApplication` annotation, case in which Spring Boot will auto scan for components in the package containing the Spring Boot main class and its sub-packages.

Java’s garbage collection cannot be relied on to clean up everything. Specifically, subclasses of `org.eclipse.swt.graphics.Resource must be manually dispose()-ed when you’re done with them.

Particularly for the Image subclass, which retains an open FileHandle for the life of the instance, failure to properly dispose of Resource`s can result in a resource leak which could bring first the application and then perhaps the box it’s on to their knees.

The use of org.fest.assertions.Assertions.assertThat by itself does nothing. You must combine it with another method that actually tests the value in use.

When the call to a function doesn’t have any side effects, what is the point of making the call if the results are ignored? In such case, either the function call is useless and should be dropped or the source code doesn’t behave as expected.

To prevent generating any false-positives, this rule triggers an issue only on the following predefined list of immutable classes in the Java API :

As well as methods of the following classes: