Learn about Java Anti-Patterns and How they help you write better code, and avoid common pitfalls.
Indexes to passed to String operations should be within the strings bounds
There are various String operations that take one or more character indexes as arguments and return a portion of the original string. Indexing in this context is zero-based, meaning that the first character’s index is 0. As a result, given a string myString, its last character is at index myString.length() - 1.
The String operation methods throw a StringIndexOutOfBoundsException when one of their index argument is smaller than 0 (E.G.: -1). String::substring also throws this exception when the beginIndex or endIndex argument is larger than myString.length(), and String::charAt when the index argument is larger than myString.length() - 1 For instance, it is not possible to use String::charAt to retrieve a value before the start or after the end of a string. Furthermore, it is not possible to use String::substring with beginIndex > endIndex to reverse the order of characters in a string.
This rule raises an issue when a negative literal or an index that is too large is passed as an argument to the String::substring, String::charAt, and related methods. It also raises an issue when the start index passed to String::substring is larger than the end index.
Use batch Processing in JDBC
Executing a batch of SQL queries instead of individual queries improves performance by reducing communication overhead with the database.
Batching SQL statements is beneficial in common situations where a SQL statement is executed within a loop. In such cases, adding the statement to a batch and subsequently executing it reduces the number of interactions with the database. This results in improved efficiency and faster execution times.
The rule raises an issue when it detects a java.sql.Statement being executed within a loop instruction, such as for, while or the forEach method of java.lang.Iterable, java.util.Map and java.util.stream.Stream.
Stream.collect() calls should not be redundant
When using the `Stream API, call chains should be simplified as much as possible to improve readability and maintainability.
This rule raises an issue when one of the following substitution can be made:
| Original | Preferred |
|---|---|
stream.collect(counting()) | stream.count() |
stream.collect(maxBy(comparator)) | stream.max(comparator) |
stream.collect(minBy(comparator)) | stream.min(comparator) |
stream.collect(mapping(mapper)) | stream.map(mapper).collect() |
stream.collect(reducing(…)) | stream.reduce(…) |
stream.collect(summingInt(mapper)) | stream.mapToInt(mapper).sum() |
stream.collect(summingLong(mapper)) | stream.mapToLong(mapper).sum() |
stream.collect(summingDouble(mapper)) | stream.mapToDouble(mapper).sum()` |
synchronized methods should not be called in loops
Synchronization can be expensive in terms of time when multiple threads need to pass through the same bottleneck /`synchronized piece of code.
If you have a piece of code calling a synchronized method once, then it only has to wait its turn to pass through the bottleneck once. But call it in a loop, and your code has to get back in line for the bottleneck over and over.
Instead, it would be better to get into the bottleneck, and then do the looping. I.e. consider refactoring the code to perform the loop inside the synchronized method.
This rule raises an issue when a synchronized` method is called in a loop.
@SuppressWarnings should be relevant
It can be useful to use in-code notation to suppress issues, but when those suppressions are no longer relevant they become a potential source of confusion and should be removed.
null should not be used with Optional
Optional acts as a container object that may or may not contain a non-null value. It is introduced in Java 8 to help avoid NullPointerException. It provides methods to check if a value is present and retrieve the value if it is present.
Optional is used instead of null values to make the code more readable and avoid potential errors.
It is a bad practice to use null with Optional because it is unclear whether a value is present or not, leading to confusion and potential NullPointerException errors.
@NonNull values should not be set to null
Fields, parameters and return values marked @NotNull, @NonNull, or @Nonnull are assumed to have non-null values and are not typically null-checked before use. Therefore setting one of these values to null, or failing to set such a class field in a constructor, could cause NullPointerExceptions at runtime.
Reluctant quantifiers in regular expressions should be followed by an expression that cant match the empty string
When a reluctant quantifier (such as `*? or +?) is followed by a pattern that can match the empty string or directly by the end of the regex, it will always match the empty string when used with methods that find partial matches (such as find, replaceAll, split etc.).
Similarly, when used with methods that find full matches, a reluctant quantifier that’s followed directly by the end of the regex (or a pattern that always matches the empty string, such as ()`) behaves indistinguishably from a greedy quantifier while being less efficient.
This is likely a sign that the regex does not work as intended.
Comparators should be Serializable
A non-serializable Comparator can prevent an otherwise-Serializable ordered collection from being serializable. Since the overhead to make a Comparator serializable is usually low, doing so can be considered good defensive programming.
Raw byte values should not be used in bitwise operations in combination with shifts
In Java, numeric promotions happen when two operands of an arithmetic expression have different sizes. More specifically, narrower operands get promoted to the type of wider operands. For instance, an operation between a byte and an int, will trigger a promotion of the byte operand, converting it into an int.
When this happens, the sequence of 8 bits that represents the byte will need to be extended to match the 32-bit long sequence that represents the int operand. Since Java uses two’s complement notation for signed number types, the promotion will fill the missing leading bits with zeros or ones, depending on the sign of the value. For instance, the byte 0b1000_0000 (equal to -128 in decimal notation), when promoted to int, will become 0b1111_1111_1111_1111_1111_1111_1000_0000.
When performing shifting or bitwise operations without considering that bytes are signed, the bits added during the promotion may have unexpected effects on the final result of the operations.
Beans in @Configuration class should have different names
Naming conventions play a crucial role in maintaining code clarity and readability. The uniqueness of bean names in Spring configurations is vital to the clarity and readability of the code. When two beans share the same name within a configuration, it is not obvious to the reader which bean is being referred to. This leads to potential misunderstandings and errors.
Overrides should match their parent class methods in synchronization
When @Overrides of synchronized methods are not themselves synchronized, the result can be improper synchronization as callers rely on the thread-safety promised by the parent class.
Object.wait(...) and Condition.await(...) should be called inside a while loop
In a multithreaded environment, the Object.wait(…), as well as Condition.await(…) and similar methods are used to pause the execution of a thread until the thread is awakened. A thread is typically awakened when it is notified, signaled, or interrupted, usually because of an event in another thread requiring some subsequent action by the waiting thread.
However, a thread may be awakened despite the desired condition not being met or the desired event not having happened. This is referred to as “spurious wakeups” and may be caused by underlying platform semantics. In other words, a thread may be awakened due to reasons that have nothing to do with the business logic. Hence, the assumption that the desired condition is met or the desired event occurred after a thread is awakened does not always hold.
According to the documentation of the Java Condition interface [1]:
The same advice is also found for the Object.wait(…) method [2]:
Types should not be specified when they can be inferred
The use of unnecessary types makes the eye stumble, and inhibits the smooth reading of code.
String#replace should be preferred to String#replaceAll
The underlying implementation of `String::replaceAll calls the java.util.regex.Pattern.compile() method each time it is called even if the first argument is not a regular expression. This has a significant performance cost and therefore should be used with care.
When String::replaceAll is used, the first argument should be a real regular expression. If it’s not the case, String::replace does exactly the same thing as String::replaceAll without the performance drawback of the regex.
This rule raises an issue for each String::replaceAll used with a String` as first parameter which doesn’t contains special regex character or pattern.
The Object.finalize() method should not be overridden
Before it reclaims storage from an object that is no longer referenced, the garbage collector calls finalize() on the object.
But there is no guarantee that this method will be called as soon as the last references to the object are removed.
It can be few microseconds to few minutes later.
For this reason relying on overriding the finalize() method to release resources or to update the state of the program is highly discouraged.
Objects should not be created only to invoke getClass
Creating an object for the sole purpose of calling getClass on it is a waste of memory and cycles. Instead, simply use the class’s .class property.
Thread.yield should not be used
Thread.yield is intended to hint to the processor that the current thread is willing to suspended in favor of another thread. Unfortunately, it doesn’t have the same results across platforms, thus marring the cross-platform compatibility of any application that uses it.
SequencedCollection methods should be used to add or remove first or last element
Java 21 introduces the new Sequenced Collections API, which is applicable to all collections with a defined sequence on their elements, such as LinkedList, TreeSet, and others (see JEP 431). For projects using Java 21 and onwards, this API should be used instead of workaround implementations that were necessary prior to Java 21.
This rule identifies instances where a workaround is used to add or remove the first or last element of a collection where the addFirst, addLast, removeFirst or removeLast method in the java.util.SequencedCollection class should have been used instead.
instanceof operators that always return true or false should be removed
instanceof operators that always return true or false are either useless or the result of a misunderstanding which could lead to unexpected behavior in production.
Local constants should follow naming conventions for constants
Shared coding conventions allow teams to collaborate efficiently. This rule checks that all local, final, initialized, primitive variables, have names that match a provided regular expression.
@Controller classes that use @SessionAttributes must call setComplete on their SessionStatus objects
A Spring @Controller that uses @SessionAttributes is designed to handle a stateful / multi-post form. Such @Controllers use the specified @SessionAttributes to store data on the server between requests. That data should be cleaned up when the session is over, but unless setComplete() is called on the SessionStatus object from a @RequestMapping method, neither Spring nor the JVM will know it’s time to do that. Note that the SessionStatus object must be passed to that method as a parameter.
Spring @Controller classes should not use @Scope
Spring `@Controllers, @Services, and @Repositorys have singleton scope by default, meaning only one instance of the class is ever instantiated in the application. Defining any other scope for one of these class types will result in needless churn as new instances are created and destroyed. In a busy web application, this could cause a significant amount of needless additional load on the server.
This rule raises an issue when the @Scope annotation is applied to a @Controller, @Service, or @Repository with any value but “singleton”. @Scope(“singleton”)` is redundant, but ignored.
ThreadLocal.withInitial should be preferred
Java 8 introduced `ThreadLocal.withInitial which is a simpler alternative to creating an anonymous inner class to initialise a ThreadLocal instance.
This rule raises an issue when a ThreadLocal anonymous inner class can be replaced by a call to ThreadLocal.withInitial`.
Synchronizing on a Lock object should be avoided
java.util.concurrent.locks.Lock offers far more powerful and flexible locking operations than are available with synchronized blocks. So synchronizing on a Lock instance throws away the power of the object, as it overrides its better locking mechanisms. Instead, such objects should be locked and unlocked using one of their lock and unlock method variants.
Floating point numbers should not be tested for equality
Floating point math is imprecise because of the challenges of storing such values in a binary representation. Even worse, floating point math is not associative; push a `float or a double through a series of simple mathematical operations and the answer will be different based on the order of those operation because of the rounding that takes place at each step.
Even simple floating point assignments are not simple:
float f = 0.1; // 0.100000001490116119384765625 double d = 0.1; // 0.1000000000000000055511151231257827021181583404541015625
(Results will vary based on compiler and compiler settings);
Therefore, the use of the equality (==) and inequality (!=) operators on float or double values is almost always an error. Instead the best course is to avoid floating point comparisons altogether. When that is not possible, you should consider using one of Java’s float-handling Numbers such as BigDecimal which can properly handle floating point comparisons. A third option is to look not for equality but for whether the value is close enough. I.e. compare the absolute value of the difference between the stored value and the expected value against a margin of acceptable error. Note that this does not cover all cases (NaN and Infinity` for instance).
This rule checks for the use of direct and indirect equality/inequailty tests on floats and doubles.
Either fields or getters should be annotated for persistence but not both
Persistence annotations should be marked either on fields or on getters but not on both. Mix the two and the annotated fields will be ignored. The potential results are that your database tables are not created or not populated (and read) correctly.
Chained AssertJ assertions should be simplified to the corresponding dedicated assertion
AssertJ contains many assertions methods specific to common types. Both versions will test the same things, but the dedicated one will provide a better error message, simplifying the debugging process.
This rule reports an issue when an assertion can be simplified to a dedicated one.
The array below gives a non-exhaustive list of assertion reported by the rule. Code behaving similarly, or with a negation will also be reported.
| Original | Dedicated |
|---|---|
Related to Object | |
`assertThat(getObject()).isEqualTo(null) | assertThat(getObject()).isNull() |
assertThat(getBoolean()).isEqualTo(true) | assertThat(getBoolean()).isTrue() |
assertThat(getBoolean()).isEqualTo(false) | assertThat(getBoolean()).isFalse() |
assertThat(x.equals(y)).isTrue() | assertThat(x).isEqualTo(y) |
Use of the @Async annotation on methods declared within a @Configuration class in Spring Boot
@Configuration is a class-level annotation indicating that an object is a source of bean definitions. @Configuration classes declare beans through @Bean-annotated methods. Calls to @Bean methods on @Configuration classes can also be used to define inter-bean dependencies. The @Bean annotation indicates that a method instantiates, configures, and initializes a new object to be managed by the Spring IoC container.
Annotating a method of a bean with @Async will make it execute in a separate thread. In other words, the caller will not wait for the completion of the called method.
The @Async annotation is not supported on methods declared within a @Configuration class. This is because @Async methods are typically used for asynchronous processing, and they require certain infrastructure to be set up, which may not be available or appropriate in a @Configuration class.
hashCode and toString should not be called on array instances
The purpose of the hashCode method is to return a hash code based on the contents of the object. Similarly, the purpose of the toString method is to provide a textual representation of the object’s contents.
Calling hashCode() and toString() directly on array instances should be avoided because the default implementations provided by the Object class do not provide meaningful results for arrays. hashCode() returns the array’s “identity hash code”, and toString() returns nearly the same value. Neither method’s output reflects the array’s contents.
Avoid using boxed Boolean types directly in boolean expressions
When boxed type java.lang.Boolean is used as an expression to determine the control flow (as described in Java Language Specification §4.2.5 The boolean Type and boolean Values) it will throw a NullPointerException if the value is null (as defined in Java Language Specification §5.1.8 Unboxing Conversion).
It is safer to avoid such conversion altogether and handle the null value explicitly.
Note, however, that no issues will be raised for Booleans that have already been null-checked.
Iterator.next() methods should throw NoSuchElementException
The java.util.Iterator.next() method must throw a NoSuchElementException when there are no more elements in the iteration. Any other behavior is non-compliant with the API contract and may cause unexpected behavior for users.
Non-serializable classes should not have serialVersionUIDs
A serialVersionUID field is required in a Serializable class. In a non-Serializable, it’s just confusing.
Method references should be used
Method references are specialized lambda expressions for methods that already have a name. They take the form of objectReference::methodName or ClassName::methodName. When a lambda does nothing but call an existing method, it can be much clearer to use a method reference instead.
Recursion should not be infinite
Recursion is a technique to solve a computational problem by splitting it into smaller problems. A method is recursive, if it splits its input into smaller instances and calls itself on these instances. This continues until a smallest input, a base case, is reached that can not be split further. Similarly, recursion can also occur when multiple methods invoke each other.
Recursion is a useful tool, but it must be used carefully. Recursive methods need to detect base cases and end recursion with a return statement.
When this is not the case, recursion will continue until the stack overflows and the
program crashes due to a StackOverflowError.
Standard functional interfaces should not be redefined
Just as there is little justification for writing your own String class, there is no good reason to re-define one of the existing, standard functional interfaces.
Doing so may seem tempting, since it would allow you to specify a little extra context with the name. But in the long run, it will be a source of confusion, because maintenance programmers will wonder what is different between the custom functional interface and the standard one.
Escaped Unicode characters should not be used
The use of Unicode escape sequences should be reserved for characters that would otherwise be ambiguous, such as unprintable characters.
This rule ignores sequences composed entirely of Unicode characters, but otherwise raises an issue for each Unicode character that represents a printable character.
Factory methods should be used when available
The use of factory methods lets you abstract the job you need to do from the specific tool implementations needed to do it with, and helps insulate you from changes.
This rule raises an issue when instances of these are instantiated directly:
`javax.xml.parsers.DocumentBuilder
javax.xml.parsers.SAXParser
javax.xml.transform.Transformer
org.xml.sax.XMLReader
org.xml.sax.XMLFilter
org.w3c.dom.*`
TrustManagers should not blindly accept any certificates
Empty implementations of the `X509TrustManager interface are often created to allow connection to a host that is not signed by a root certificate authority. Such an implementation will accept any certificate, which leaves the application vulnerable to Man-in-the-middle attacks. The correct solution is to provide an appropriate trust store.
This rule raises an issue when an implementation of X509TrustManager` never throws exception.
@Autowired should be used when multiple constructors are provided
The Spring dependency injection mechanism cannot identify which constructor to use for auto-wiring when multiple constructors are present in a class. This ambiguity can cause the application to crash at runtime, and it makes the code less clear to understand and more complex to extend and maintain.
Local-Variable Type Inference should be used
In Java 10 Local-Variable Type Inference was introduced. It allows you to omit the expected type of a variable by declaring it with the `var keyword.
While it is not always possible or cleaner to use this new way of declaring a variable, when the type on the left is the same as the one on the right in an assignment, using the var` will result in a more concise code.
This rule reports an issue when the expected type of the variable is the same as the returned type of assigned expression and the type can be easily inferred by the reader, either when the type is already mentioned in the name or the initializer, or when the expression is self-explanatory.
Collection constructors should not be used as java.util.function.Function
It is very common to pass a collection constructor reference as an argument, for example `Collectors.toCollection(ArrayList::new) takes the ArrayList::new constructor. When the method expects a java.util.function.Supplier it is perfectly fine. However when the method argument type is java.util.function.Function it means that an argument will be passed to the constructor.
The first argument of Collections constructors is usually an integer representing its “initial capacity”. This is generally not what the developer expects, but the memory allocation is not visible at first glance.
This rule raises an issue when a collection constructor is passed by reference as a java.util.function.Function` argument.
Exceptions in throws clauses should not be superfluous
Superfluous exceptions within throws clauses have negative effects on the readability and maintainability of the code. An exception in a throws clause is superfluous if it is:
listed multiple times
a subclass of another listed exception
not actually thrown by any execution path of the method
JUnit framework methods should be declared properly
If the `suite method in a JUnit 3 TestCase is not declared correctly, it will not be used. Such a method must be named “suite”, have no arguments, be public static, and must return either a junit.framework.Test or a junit.framework.TestSuite.
Similarly, setUp and tearDown` methods that aren’t properly capitalized will also be ignored.
Stream.toList() method should be used instead of collectors when unmodifiable list needed
In Java 8 Streams were introduced to support chaining of operations over collections in a functional style. The most common way to save a result of such chains is to save them to some collection (usually List). To do so there is a terminal method collect that can be used with a library of Collectors. The key problem is that .collect(Collectors.toList()) actually returns a mutable kind of List while in the majority of cases unmodifiable lists are preferred. In Java 10 a new collector appeared to return an unmodifiable list: toUnmodifiableList(). This does the trick but results in verbose code. Since Java 16 there is now a better variant to produce an unmodifiable list directly from a stream: Stream.toList().
This rule raises an issue when “collect” is used to create a list from a stream.
Unsupported methods should not be called
There are several reasons that a class might have a method that throws an `UnsupportedOperationException. The method may be required by an interface or an abstract superclass but not actually needed in the class. Or it may be that the class itself is intended as a superclass, and the method may optionally be implemented by subclasses but not invoked on the superclass. Finally, it could be that the method has been stubbed into the code but not implemented yet.
Whatever the reason, methods that throw UnsupportedOperationException` should not be called.
Limited dependence should be placed on operator precedence
The rules of operator precedence are complicated and can lead to errors. For this reason, parentheses should be used for clarification in complex statements. However, this does not mean that parentheses should be gratuitously added around every operation.
This rule raises issues when `&& and || are used in combination, when assignment and equality or relational operators are used together in a condition, and for other operator combinations according to the following table:
| +, -, *, /, % | <<, >>, >>> | & | ^ | | | |
|---|---|---|---|---|---|
+, -, *, /, % | x | x | x | x | |
<<, >>, >>> | x | x | x | x | |
& | x | x | x | x | |
^ | x | x | x | x | |
|` | x | x | x | x |
This rule also raises an issue when the “true” or “false” expression of a ternary operator is not trivial and not wrapped inside parentheses.
Literal boolean values and nulls should not be used in assertions
There’s no reason to use literal boolean values or nulls in assertions. Instead of using them with assertEquals, assertNotEquals and similar methods, you should be using assertTrue, assertFalse, assertNull or assertNotNull instead (or isNull etc. when using Fest). Using them with assertions unrelated to equality (such as assertNull) is most likely a bug.
Supported frameworks:
JUnit3
JUnit4
JUnit5
Fest assert
serialVersionUID field should not be set to 0L in records
In Records serialization is not done the same way as for ordinary serializable or externalizable classes. Records serialization does not rely on the `serialVersionUID field, because the requirement to have this field equal is waived for record classes. By default, all records will have this field equal to 0L and there is no need to specify this field with 0L value and it is possible to specify it with some custom value to support serialization/deserialization involving ordinary classes.
This rule raises an issue when there is a private static final long serialVersionUID field which is set to 0L` in a Record class.
Entity classes should be Serializable
The Java Persistence API specification imposes only a conditional requirement that `@Entity classes be Serializable:
But it’s best practice to make all such classes Serializable from the start. So this rule raises an issue when an @Entity does not implement Serializable`.
writeObject should not be the only synchronized code in a class
Synchronization is a mechanism used when multithreading in Java to ensure that only one thread executes a given block of code at a time. This is done to avoid bugs that can occur when multiple threads share a given state and try to manipulate simultaneously.
Object serialization is not thread-safe by default. In a multithreaded environment, one option is to mark writeObject with synchronized to improve thread safety. It is highly suspicious, however, if writeObject is the only synchronized method in a class. It may indicate that serialization is not required, as multithreading is not used. Alternatively, it could also suggest that other methods in the same class have been forgotten to be made thread-safe.
Back references in regular expressions should only refer to capturing groups that are matched before the reference
When a back reference in a regex refers to a capturing group that hasn’t been defined yet (or at all), it can never be matched. Named back references throw a `PatternSyntaxException in that case; numeric back references fail silently when they can’t match, simply making the match fail.
When the group is defined before the back reference but on a different control path (like in (.)|\1` for example), this also leads to a situation where the back reference can never match.
Fields should not be initialized to default values
The compiler automatically initializes class fields to their default values before setting them with any initialization values, so there is no need to explicitly set a field to its default value. Further, under the logic that cleaner code is better code, it’s considered poor style to do so.
Extensions and implementations should not be redundant
All classes extend Object implicitly. Doing so explicitly is redundant.
Further, declaring the implementation of an interface and one if its parents is also redundant. If you implement the interface, you also implicitly implement its parents and there’s no need to do so explicitly.
Stream.peek should be used with caution
According to its JavaDocs, the intermediate Stream operation `java.util.Stream.peek() “exists mainly to support debugging” purposes.
A key difference with other intermediate Stream operations is that the Stream implementation is free to skip calls to peek() for optimization purpose. This can lead to peek() being unexpectedly called only for some or none of the elements in the Stream.
As a consequence, relying on peek()` without careful consideration can lead to error-prone code.
This rule raises an issue for each use of peek() to be sure that it is challenged and validated by the team to be meant for production debugging/logging purposes.
Bluetooth should be configured to use low power
Using high power consumption modes for Bluetooth operations can drain the device battery faster and may not be suitable for scenarios where power efficiency is crucial.
This rule identifies instances where high power consumption Bluetooth operations are used, specifically when requestConnectionPriority or setAdvertiseMode methods are invoked with arguments other than those promoting low power consumption.
Assertions should be complete
It is very easy to write incomplete assertions when using some test frameworks. This rule enforces complete assertions in the following cases:
Fest: `assertThat is not followed by an assertion invocation
AssertJ: assertThat is not followed by an assertion invocation
Mockito: verify is not followed by a method invocation
Truth: assertXXX` is not followed by an assertion invocation
In such cases, what is intended to be a test doesn’t actually verify anything
Loggers should be private static final and should share a naming convention
Unnecessary type parameters should not be inserted in method calls
Using a type parameter when you don’t have to simply obfuscates the code. Inserting an unnecessary type parameter in an unparameterized method call will compile, but confuse maintainers.
The diamond operator (<>) should be used
Java uses angular brackets ([/code> and <code]) to provide a specific type (the “type argument”) to a generic type. For instance, List is a generic type, so a list containing strings can be declared with List<String>.
Prior to Java 7, the type argument had to be provided explicitly for every occurrence where generics were used. This often caused redundancy, as the type argument would have to be provided both when a field is declared and initialized.
Java 7 introduced the diamond operator (<>) to reduce the code’s verbosity in some situations. The type argument between the angular brackets should be omitted if the compiler can infer it.
Since the diamond operator was only introduced in Java 7, this rule is automatically disabled when the project’s sonar.java.source is lower than 7.
Classes should not have members with visibility set higher than the class own visibility
There’s no point in having a public member in a non-public class because objects that can’t access the class will never have the chance to access the member.
This rule raises an issue when classes has methods, fields, or inner classes with higher visibility than the class itself has.
Object.wait(), Object.notify() and Object.notifyAll() should only be called from synchronized code
The Object.wait(…), Object.notify() and Object.notifyAll() methods are used in multithreaded environments to coordinate interdependent tasks that are performed by different threads. These methods are not thread-safe and by contract, they require the invoking Thread to own the object’s monitor. If a thread invokes one of these methods without owning the object’s monitor an IllegalMonitorStateException is thrown.
Non-serializable values should not be stored in Serializable classes
Instances of a Serializable class can be saved out to file and rehydrated at leisure. But that only works when all the values in the class instance are themselves Serializable (or transient). Storing a non-serializable value in a Serializable class will prevent the serialization of that class.
Text blocks should not be used in complex expressions
In Java 15 Text Blocks are official and can be used just like an ordinary String. However, when they are used to represent a big chunk of text, they should not be used directly in complex expressions, as it decreases the readability. In this case, it is better to extract the text block into a variable or a field.
This rule reports an issue when a text block longer than a number of lines given as a parameter is directly used within a lambda expression.
Assignment of lazy-initialized members should be the last step with double-checked locking
Double-checked locking can be used for lazy initialization of volatile fields, but only if field assignment is the last step in the synchronized block. Otherwise you run the risk of threads accessing a half-initialized object.
Value-based classes should not be used for locking
According to the documentation,
This is because value-based classes are intended to be wrappers for value types, which will be primitive-like collections of data (similar to `structs in other languages) that will come in future versions of Java.
This means that you can’t be sure you’re the only one trying to lock on any given instance of a value-based class, opening your code up to contention and deadlock issues.
Under Java 8 breaking this rule may not actually break your code, but there are no guarantees of the behavior beyond that.
This rule raises an issue when a known value-based class is used for synchronization. That includes all the classes in the java.time package except Clock; the date classes for alternate calendars, HijrahDate, JapaneseDate, MinguoDate, ThaiBuddhistDate; and the optional classes: Optional, OptionalDouble, OptionalLong, OptionalInt.
Note that this rule is automatically disabled when the project’s sonar.java.source is lower than 8`.
null should not be returned from a Boolean method
Callers of a Boolean method may be expecting to receive true or false in response. But Boolean objects can take null as a possible value. Boolean methods should not return null unless the code is annotated appropriately. With the proper annotation, the caller is aware that the returned value could be null.
Whitespace and control characters in literals should be explicit
Non-encoded control characters and whitespace characters are often injected in the source code because of a bad manipulation. They are either invisible or difficult to recognize, which can result in bugs when the string is not what the developer expects. If you actually need to use a control character use their encoded version (ex: ASCII `\n,\t,… or Unicode U+000D, U+0009,…).
This rule raises an issue when the following characters are seen in a literal string:
ASCII control character. (character index < 32 or = 127)
Unicode whitespace characters.
Unicode C0 control characters
Unicode characters U+200B, U+200C, U+200D, U+2060, U+FEFF, U+2028, U+2029
No issue will be raised on the simple space character. Unicode U+0020`, ASCII 32.
Serializable inner classes of Serializable classes should be static
Serializing a non-`static inner class will result in an attempt at serializing the outer class as well. If the outer class is actually serializable, then the serialization will succeed but possibly write out far more data than was intended.
Making the inner class static (i.e. “nested”) avoids this problem, therefore inner classes should be static if possible. However, you should be aware that there are semantic differences between an inner class and a nested one:
an inner class can only be instantiated within the context of an instance of the outer class.
a nested (static`) class can be instantiated independently of the outer class.
Classes should be usable
Classes without public static members cannot be used without being instantiated, but classes with only private constructors cannot be instantiated. When a class has only private constructors and no static members, it is useless and should be removed or refactored.
EJBs should not not have non-final static fields
According to the specification:
Therefore, all static fields in an EJB should also be final`.
write(byte[],int,int) should be overridden
When directly subclassing `java.io.OutputStream or java.io.FilterOutputStream, the only requirement is that you implement the method write(int). However most uses for such streams don’t write a single byte at a time and the default implementation for write(byte[],int,int) will call write(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 write(byte[],int,int).
This rule raises an issue when a direct subclass of java.io.OutputStream or java.io.FilterOutputStream doesn’t provide an override of write(byte[],int,int)`.
Default annotation parameter values should not be passed as arguments
Specifying the default value for an annotation parameter is redundant. Such values should be omitted in the interests of readability.
Throwable.printStackTrace(...) should not be called
`Throwable.printStackTrace(…) prints a Throwable and its stack trace to some stream. By default that stream System.Err, which could inadvertently expose sensitive information.
Loggers should be used instead to print Throwables, as they have many advantages:
Users are able to easily retrieve the logs.
The format of log messages is uniform and allow users to browse the logs easily.
This rule raises an issue when printStackTrace` is used without arguments, i.e. when the stack trace is printed to the default stream.
PreparedStatement and ResultSet methods should be called with valid indices
PreparedStatement is an object that represents a precompiled SQL statement, that can be used to execute the statement multiple times efficiently.
ResultSet is the Java representation of the result set of a database query obtained from a Statement object. A default ResultSet object is not updatable and has a cursor that moves forward only.
The parameters in PreparedStatement and ResultSet are indexed beginning at 1, not 0. When an invalid index is passed to the PreparedStatement or ResultSet methods, an IndexOutOfBoundsException is thrown. This can cause the program to crash or behave unexpectedly, leading to a poor user experience.
This rule raises an issue for the get methods in PreparedStatement and the set methods in ResultSet.
Threads should not be started in constructors
The problem with invoking `Thread.start() in a constructor is that you’ll have a confusing mess on your hands if the class is ever extended because the superclass’ constructor will start the thread before the child class has truly been initialized.
This rule raises an issue any time start is invoked in the constructor of a non-final` class.
Async methods should return void or Future
The Spring framework provides the annotation Async to mark a method (or all methods of a type) as a candidate for asynchronous execution.
Asynchronous methods do not necessarily, by their nature, return the result of their calculation immediately. Hence, it is unexpected and in clear breach of the Async contract for such methods to have a return type that is neither void nor a Future type.
Composed @RequestMapping variants should be preferred
Spring framework 4.3 introduced variants of the @RequestMapping annotation to better represent the semantics of the annotated methods. The use of @GetMapping, @PostMapping, @PutMapping, @PatchMapping and @DeleteMapping should be preferred to the use of the raw @RequestMapping(method = RequestMethod.XYZ).
Case insensitive string comparisons should be made without intermediate upper or lower casing
Using toLowerCase() or toUpperCase() to make case insensitive comparisons is inefficient because it requires the creation of temporary, intermediate String objects.
Swing components should not be created or shown from the main thread
Swing interfaces should be constructed and shown from the Swing event dispatch thread. Doing so from any other thread, such as from `main risks deadlocks since you run the risk of multiple threads accessing things which are inherently not thread-safe.
Instead, use SwingUtilities.invokeLater or SwingUtilities.invokeAndWait to kick off a new Runnable` that handles your GUI creation.
DateTimeFormatters should not use mismatched year and week numbers
When creating a `DateTimeFormatter using the WeekFields.weekBasedYear() temporal field, the resulting year number may be off by 1 at the beginning of a new year (when the date to format is in a week that is shared by two consecutive years).
Using this year number in combination with an incompatible week temporal field yields a result that may be confused with the first week of the previous year.
Instead, when paired with a week temporal field, the week-based year should only be used with the week of week-based year temporal field WeekFields.weekOfWeekBasedYear().
Alternatively the temporal field ChronoField.ALIGNED_WEEK_OF_YEAR` can be used together with a regular year (but not the week based year).
Escape sequences should not be used in text blocks
The use of escape sequences is mostly unnecessary in text blocks.
Model attributes should follow the Java identifier naming convention
Spring Expression Language (SpEL) is an expression language used in the Spring Framework for evaluating and manipulating objects, properties, and conditions within Spring-based applications.
org.springframework.ui.Model is an interface in the Spring Framework that represents a container for data that can be passed between a controller and a view in a Spring MVC web application, allowing for data sharing during the request-response cycle.
Attributes added to the org.springframework.ui.Model should follow the Java identifier naming convention, which means they must start with a letter a-z, A-Z, underscore _, or a dollar sign $ and may be followed by letters, digits, underscores, or dollar signs.
Failure to do so may result in SpEL parsing errors when using these attributes in template engines.
Class.newInstance should not be used when the default constructor throws exceptions
Calling `Class.newInstance invokes the class’ default constructor. Unfortunately, since it’s not a direct call to the constructor, compile-time checking will be unable to detect the possibility. This means that your code will compile even if you haven’t put the invocation in a try block.
On the other hand, Construtor.newInstance handles exceptions by wrapping them in an InvocationTargetException and explicitly throwing them.
This rule raises an issue when Class.newInstance` is used to invoke a constructor that throws checked exceptions.
Constructors should not be used to instantiate String, BigInteger, BigDecimal and primitive-wrapper classes
Calling constructors for String, BigInteger, BigDecimal and the objects used to wrap primitives is less efficient and less clear than relying on autoboxing or valueOf.
Consider simplifying when possible for more efficient and cleaner code.
SpEL expression should have a valid syntax
SpEL is used in Spring annotations and is parsed by the Spring framework, not by the Java compiler. This means that invalid SpEL expressions are not detected during Java compile time. They will cause exceptions during runtime instead, or even fail silently with the expression string interpreted as a simple string literal by Spring.
java.io should not be used from EJBs
To ensure EJB portability, the EJB specification forbids the use of functionality in the `java.io package. Instead of reading and writing files, EJB’s should use some other means of data storage and retrieval, such as JDBC.
This rule raises an issue for the first java.io` method call in each method.
Classes should not have too many static imports
Importing a class statically allows you to use its public static members without qualifying them with the class name. That can be handy, but if you import too many classes statically, your code can become confusing and difficult to maintain.
private and final methods that dont access instance data should be static
Non-overridable methods (private or final) that don’t access instance data can be static to prevent any misunderstanding about the contract of the method.
Classes without public constructors should be final
Classes with only private constructors should be marked final to prevent any mistaken extension attempts.
Method overrides should not change contracts
Because a subclass instance may be cast to and treated as an instance of the superclass, overriding methods should uphold the aspects of the superclass contract that relate to the Liskov Substitution Principle. Specifically, if the parameters or return type of the superclass method are marked with any of the following: @Nullable, @CheckForNull, @NotNull, @NonNull, and @Nonnull, then subclass parameters are not allowed to tighten the contract, and return values are not allowed to loosen it.
Members of Spring components should be injected
Spring `@Component, @Controller, @RestController,@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.
This rule raises an issue when a singleton @Component, @Controller, @RestController, @Service, or @Repository, not annotated with @ConfigurationProperties, has non-static members that are not annotated with one of:
org.springframework.beans.factory.annotation.Autowired
org.springframework.beans.factory.annotation.Value
javax.annotation.Inject
javax.annotation.Resource`
Reverse view should be used instead of reverse copy in read-only cases
Java 21 introduces the new Sequenced Collections API, which applies to all collections with a defined sequence on their elements, such as LinkedList, TreeSet, and others (see JEP 431). For projects using Java 21 and onwards, use this API instead of workaround implementations that were necessary before Java 21. One of the features of the new Sequenced Collections API is SequencedCollection.reversed() which returns a lightweight view of the original collection, in the reverse order.
This rule reports when reverse view would have been sufficient instead of a reverse copy of a sequenced collection created using a list constructor plus a Collections.reverse(collection); call.
If feasible, a view should be preferred over a copy because a view is a lightweight iterator without modification of the list itself.
Abstract class names should comply with a naming convention
Sharing some naming conventions is a key point to make it possible for a team to efficiently collaborate. This rule allows to check that all abstract class names match a provided regular expression. If a non-abstract class match the regular expression, an issue is raised to suggest to either make it abstract or to rename it.
The Singleton design pattern should be used with care
While the Singleton pattern can be useful in certain situations, overusing it can have several drawbacks:
Tight coupling: The Singleton pattern can create tight coupling between the Singleton class and other classes that use it, making the code difficult to maintain and modify.
Global state: The Singleton pattern can create a global state, making it difficult to manage the state of the application and leading to unexpected behavior.
Testing: The Singleton pattern can make it difficult to test classes that depend on the Singleton, as the Singleton cannot be easily substituted with a mock object.
Scalability: The Singleton pattern can make it difficult to scale an application, as it can create a bottleneck if multiple threads try to access the Singleton concurrently.
Dependency injection: The Singleton pattern can make it difficult to use dependency injection frameworks, as the Singleton instance is usually created statically.
In general, the Singleton pattern should be used sparingly and only in situations where it provides a clear benefit over other patterns or approaches. It is important to consider the drawbacks and tradeoffs of using the Singleton pattern before incorporating it into an application.
Consumer Builders should be used
Some API, like the AWS SDK, heavily rely on the builder pattern to create different data structures. Despite all the benefits, this pattern can become really verbose, especially when dealing with nested structures. In order to reach a more concise code, “Consumer Builders”, also called “Consumer Interface” are often introduced.
The idea is to overload the methods taking others structures in a Builder with a Consumer of Builder instead. This enables to use a lambda instead of nesting another Builder, resulting in more concise and readable code.
This rule reports an issue when the Consumer Builder methods could be used instead of the classical ones.
Parentheses should be removed from a single lambda parameter when its type is inferred
Lambda expressions with only one argument with an inferred type (i.e., no explicit type declaration) can be written without parentheses around that single parameter. This syntax is simpler, more compact and readable than using parentheses and is therefore preferred.
This rule is automatically disabled when the project’s sonar.java.source is lower than 8, as lambda expressions were introduced in Java 8.
Some Java packages or classes should not be used
This rule raises an issue when a configured Java package or class is used.
Operator instanceof should be used instead of A.class.isInstance()
The `instanceof construction is a preferred way to check whether a variable can be cast to some type statically because a compile-time error will occur in case of incompatible types. The method isInstance() from java.lang.Class works differently and does type check at runtime only, incompatible types will therefore not be detected early in the development, potentially resulting in dead code. The isInstance() method should only be used in dynamic cases when the instanceof operator can’t be used.
This rule raises an issue when isInstance() is used and could be replaced with an instanceof` check.
Optional should not be used for parameters
The Java language authors have been quite frank that `Optional was intended for use only as a return type, as a way to convey that a method may or may not return a value.
And for that, it’s valuable but using Optional on the input side increases the work you have to do in the method without really increasing the value. With an Optional parameter, you go from having 2 possible inputs: null and not-null, to three: null, non-null-without-value, and non-null-with-value. Add to that the fact that overloading has long been available to convey that some parameters are optional, and there’s really no reason to have Optional parameters.
The rule also checks for Guava’s Optional, as it was the inspiration for the JDK Optional. Although it is different in some aspects (serialization, being recommended for use as collection elements), using it as a parameter type causes exactly the same problems as for JDK Optional`.
Unsupported methods should not be called on some collection implementations
The Java Collections framework defines interfaces such as java.util.List or java.util.Map. Several implementation classes are provided for each of those interfaces to fill different needs: some of the implementations guarantee a few given performance characteristics, some others ensure a given behavior, for example immutability.
Among the methods defined by the interfaces of the Collections framework, some are declared as “optional”: an implementation class may choose to throw an UnsupportedOperationException when one of those methods is called. For example, java.util.Collections.emptyList() returns an implementation of java.util.List which is documented as “immutable”. Calling the add method on this object triggers an UnsupportedOperationException.
Methods should not perform too many tasks (aka Brain method)
This issue is raised when Sonar considers that a method is a ‘Brain Method’. A Brain Method is a method that tends to centralize its owner’s class logic and generally performs too many operations. This can include checking too many conditions, using lots of variables, and ultimately making it difficult to understand, maintain and reuse. It is characterized by high LOC number, high cyclomatic and cognitive complexity, and a large number of variables being used.
contains should not be used on hash classes
Two “hash” classes, Hashtable, and ConcurrentHashMap offer contains methods. One might naively assume that the contains method searches both keys and values for its argument. And one would be wrong. Because these legacy methods search only values, they are likely to mislead maintainers even if the original coder understood precisely what’s going on.
Map.get and value test should be replaced with single method call
It’s a common pattern to test the result of a `java.util.Map.get() against null or calling java.util.Map.containsKey() before proceeding with adding or changing the value in the map. However the java.util.Map API offers a significantly better alternative in the form of the computeIfPresent() and computeIfAbsent() methods. Using these instead leads to cleaner and more readable code.
Note that this rule is automatically disabled when the project’s sonar.java.source` is not 8.
An iteration on a Collection should be performed on the type handled by the Collection
When iterating over an Iterable with a for loop, the iteration variable could have the same type as the type returned by the iterator (the item type of the Iterable). This rule reports when a supertype of the item type is used for the variable instead, but the variable is then explicitly downcast in the loop body.
Using explicit type casts instead of leveraging the language’s type system is a bad practice. It disables static type checking by the compiler for the cast expressions, but potential errors will throw a ClassCastException during runtime instead.
Use built-in Math.clamp methods
In Java 21 the java.lang.Math class was updated with the static method Math.clamp, to clamp a numerical value between a min and a max value.
Using this built-in method is now the preferred way to restrict to a given interval, as it is more readable and less error-prone.
Class fields should be initialized
Class members that are not assigned a default value and are not initialized in a constructor will be set to null by the compiler. Even if code exists to properly set those members, there is a risk that they will be dereferenced before it is called, resulting in a NullPointerException.
Because you cannot guarantee that such classes will always be used properly, class members should always be initialized.
This rule flags members which have no default value and which are left uninitialized by at least one class constructor, but which are unconditionally dereferenced somewhere in the code.
Preconditions and logging arguments should not require evaluation
Some method calls can effectively be “no-ops”, meaning that the invoked method does nothing, based on the application’s configuration (eg: debug logs in production). However, even if the method effectively does nothing, its arguments may still need to evaluated before the method is called.
Passing message arguments that require further evaluation into a Guava com.google.common.base.Preconditions check can result in a performance penalty. That is because whether or not they’re needed, each argument must be resolved before the method is actually called.
Similarly, passing concatenated strings into a logging method can also incur a needless performance hit because the concatenation will be performed every time the method is called, whether or not the log level is low enough to show the message.
Instead, you should structure your code to pass static or pre-computed values into Preconditions conditions check and logging calls.
Specifically, the built-in string formatting should be used instead of string concatenation, and if the message is the result of a method call, then Preconditions should be skipped altogether, and the relevant exception should be conditionally thrown instead.
equals should only be used for methods that override Object.equals(Object)
”equals” has a special place as a method name: it is expected to override boolean Object.equals(Object). Using the name for a method with some other signature is a recipe for confusion.
Null checks should not be used with instanceof
There’s no need to null test in conjunction with an instanceof test. null is not an instanceof anything, so a null check is redundant.
Custom getter method should not be used to override records getter behavior
Before records appeared in Java 16, there was a common way to represent getters for private fields of a class: a method named “get” with a capitalized field name. For example, for a `String field named “myField” the signature of the getter method will be: public String getMyField()
In records, getters are named differently. Getters created by default do not contain the “get” prefix. So for a record’s String field “myField” the getter method will be: public String myField()`
This means that if you want to override the default getter behavior it is better to use the method provided by records instead of creating a new one. Otherwise, this will bring confusion to the users of the record as two getters will be available and even leads to bugs if the behavior is different from the default one.
This rule raises an issue when a record contains a getter named “get” with a capitalized field name that is not behaving the same as the default one.
Bean names should adhere to the naming conventions
Consistent naming of beans is important for the readability and maintainability of the code. More precisely, according to the Spring documentation:
Naming beans consistently makes your configuration easier to read and understand, and if you are using Spring AOP it helps a lot when applying advice to a set of beans related by name.
Not following accepted conventions can introduce inconsistent naming, especially when multiple developers work on the same project, leading to technical debt.
The spring documentation establishes a naming convention that consists of camel-cased names with a leading lowercase letter.
This rule raises an issue when a bean name defined in one of the following annotations does not adhere to the naming convention:
@Bean
@Configuration
@Controller
@Component
@Qualifier
@Repository
@Service
Dependencies and plugin declarations should not be duplicated
There is no need to declare the same dependency or plugin twice in a project. In fact, doing so is likely to cause errors in the future when maintainers try to change or upgrade the plugin or dependency.
Public methods should throw at most one checked exception
Using checked exceptions forces method callers to deal with errors, either by propagating them or by handling them. Throwing exceptions makes them fully part of the API of the method.
But to keep the complexity for callers reasonable, methods should not throw more than one kind of checked exception.
Cast operations should not trigger a ClassCastException
A cast operation allows an object to be “converted” from one type to another. The compiler raises an error if it can determine that the target type is incompatible with the declared type of the object, otherwise it accepts the cast. However, depending on the actual runtime type of the object, a cast operation may fail at runtime. When a cast operation fails, a ClassCastException is thrown.
Nested enums should not be declared static
In Java, an enum is a special data type that allows you to define a set of constants. Nested enum types, also known as inner enum types, are enum types that are defined within another class or interface.
Nested enum types are implicitly static, so there is no need to declare them static explicitly.
JNI should not be used
JNI (Java Native Interface) code should be used only as a last resort, since part of the point of using Java is to make applications portable, and by definition the use of JNI can reduce portability.
Non-primitive fields should not be volatile
Marking an array `volatile means that the array itself will always be read fresh and never thread cached, but the items in the array will not be. Similarly, marking a mutable object field volatile means the object reference is volatile but the object itself is not, and other threads may not see updates to the object state.
This can be salvaged with arrays by using the relevant AtomicArray class, such as AtomicIntegerArray, instead. For mutable objects, the volatile` should be removed, and some other method should be used to ensure thread-safety, such as synchronization, or ThreadLocal storage.
Synchronization should not be done on java.util.concurrent collections
Collection classes from the `java.util.concurrent package have their own concurrency control mechanisms. A concurrent collection is thread-safe, but not governed by a single exclusion lock, therefore using an instance of such a class for synchronization is, at best unnecessary and at worst likely to have unintended consequences.
This rule raises an issue when a synchronization lock is used on an instance of one of the collection classes from the java.util.concurrent` package.
.add() and .addAll() should not be invoked on Map and SequencedMap entries views
The Collection object returned by Map.entrySet(), Map.keySet() and Map.values(), and SequencedMap.sequencedEntrySet(), SequencedMap.sequencedKeySet() and SequencedMap.sequencedValues(), do not support the .add() and .addAll() methods, and they will throw an UnsupportedOperationException when invoked.
This rule raises an issue whenever .add() or .addAll() are invoked on collections that were retrieved this way.
Simple class names should be used
Java’s import mechanism allows the use of simple class names. Therefore, using a class' fully qualified name in a file that imports the class is redundant and confusing.
Nullable injected fields and parameters should provide a default value
The @Value annotation does not guarantee that the property is defined. Particularly if a field or parameter is annotated as nullable, it indicates that the developer assumes that the property may be undefined.
An undefined property may lead to runtime exceptions when the Spring framework tries to inject the autowired dependency during bean creation.
This rule raises an issue when a nullable field or parameter is annotated with @Value and no default value is provided.
iterator should not return this
An Iterable should not implement the Iterator interface or return this as an Iterator. The reason is that Iterator represents the iteration process itself, while Iterable represents the object we want to iterate over.
The Iterator instance encapsulates state information of the iteration process, such as the current and next element. Consequently, distinct iterations require distinct Iterator instances, for which Iterable provides the factory method Iterable.iterator().
This rule raises an issue when the Iterable.iterator() of a class implementing both Iterable and Iterator returns this.
static parent class methods should not be shadowed
Shadowing parent class static methods by creating methods in child classes with the same signatures can result in seemingly strange behavior if an instance of the child class is cast to the parent class and the static method is invoked using a reference to the child class. In such cases, the parent class’ code will be executed instead of the code in the child class, confusing callers and potentially causing hard-to-find bugs. Instead the child class method should be renamed.
Redundant constructors/methods should be avoided in records
In Java 16 records represent a brief notation for immutable data structures. Records have autogenerated implementations for constructors with all parameters, getters, equals, hashcode and toString. Although these methods can still be overridden inside records, there is no use to do so if no special logic is required.
This rule reports an issue on empty compact constructors, trivial canonical constructors and simple getter methods with no additional logic.
AES encryption algorithm should be used with secured mode
The Advanced Encryption Standard (AES) encryption algorithm can be used with various modes. Some combinations are not secured:
Electronic Codebook (ECB) mode: Under a given key, any given plaintext block always gets encrypted to the same ciphertext block. Thus, it does not hide data patterns well. In some senses, it doesn’t provide serious message confidentiality, and it is not recommended for use in cryptographic protocols at all.
Cipher Block Chaining (CBC) with PKCS#5 padding (or PKCS#7) is susceptible to padding oracle attacks.
In both cases, Galois/Counter Mode (GCM) with no padding should be preferred.
This rule raises an issue when a Cipher instance is created with either ECB or CBC/PKCS5Padding mode.
Invalid Date values should not be used
Whether the valid value ranges for `Date fields start with 0 or 1 varies by field. For instance, month starts at 0, and day of month starts at 1. Enter a date value that goes past the end of the valid range, and the date will roll without error or exception. For instance, enter 12 for month, and you’ll get January of the following year.
This rule checks for bad values used in conjunction with java.util.Date, java.sql.Date, and java.util.Calendar`. Specifically, values outside of the valid ranges:
| Field | Valid |
|---|---|
month | 0-11 |
date (day) | 0-31 |
hour | 0-23 |
minute | 0-60 |
second | 0-61 |
Note that this rule does not check for invalid leap years, leap seconds (second = 61), or invalid uses of the 31st day of the month.
Unit tests should throw exceptions
When the code under test in a unit test throws an exception, the test itself fails. Therefore, there is no need to surround the tested code with a `try-catch structure to detect failure. Instead, you can simply move the exception type to the method signature.
This rule raises an issue when there is a fail assertion inside a catch` block.
Supported frameworks:
JUnit3
JUnit4
JUnit5
Fest assert
AssertJ
Similar tests should be grouped in a single Parameterized test
When multiple tests differ only by a few hardcoded values they should be refactored as a single “parameterized” test. This reduces the chances of adding a bug and makes them more readable. Parameterized tests exist in most test frameworks (JUnit, TestNG, etc…).
The right balance needs of course to be found. There is no point in factorizing test methods when the parameterized version is a lot more complex than initial tests.
This rule raises an issue when at least 3 tests could be refactored as one parameterized test with less than 4 parameters. Only test methods which have at least one duplicated statement are considered.
Collection.toArray() should be passed an array of the proper type
The Collection.toArray() method returns an Object[] when no arguments are provided to it. This can lead to a ClassCastException at runtime if you try to cast the returned array to an array of a specific type. Instead, use this method by providing an array of the desired type as the argument.
Note that passing a new T[0] array of length zero as the argument is more efficient than a pre-sized array new T[size].
Regular expressions should not overflow the stack
The Java regex engine uses recursive method calls to implement backtracking. Therefore when a repetition inside a regular expression contains multiple paths (i.e. the body of the repetition contains an alternation (`|), an optional element or another repetition), trying to match the regular expression can cause a stack overflow on large inputs. This does not happen when using a possessive quantifier (such as + instead of ) or when using a character class inside a repetition (e.g. [ab] instead of (a|b)).
The size of the input required to overflow the stack depends on various factors, including of course the stack size of the JVM. One thing that significantly increases the size of the input that can be processed is if each iteration of the repetition goes through a chain of multiple constant characters because such consecutive characters will be matched by the regex engine without invoking any recursion.
For example, on a JVM with a stack size of 1MB, the regex (?:a|b)* will overflow the stack after matching around 6000 characters (actual numbers may differ between JVM versions and even across multiple runs on the same JVM) whereas (?:abc|def)* can handle around 15000 characters.
Since often times stack growth can’t easily be avoided, this rule will only report issues on regular expressions if they can cause a stack overflow on realistically sized inputs. You can adjust the maxStackConsumptionFactor` parameter to adjust this.
Using setters in Struts 2 ActionSupport is security-sensitive
2 ActionSupport is security-sensitive. For example, their use has led in the past to the following vulnerabilities:
All classes extending com.opensymphony.xwork2.ActionSupport are potentially remotely reachable. An action class extending ActionSupport will receive all HTTP parameters sent and these parameters will be automatically mapped to the setters of the Struts 2 action class. One should review the use of the fields set by the setters, to be sure they are used safely. By default, they should be considered as untrusted inputs.
Track uses of @SuppressWarnings annotations
This rule allows you to track the usage of the @SuppressWarnings mechanism.
compareTo results should not be checked for specific values
Assuming that a comparator or compareTo method always returns -1 or 1 if the first operand is less than or greater than the second is incorrect.
The specifications for both methods, Comparator.compare and Comparable.compareTo, state that their return value is “a negative integer, zero, or a positive integer as this object is less than, equal to, or greater than the specified object.” Even if a specific comparator always returns -1, 0, or 1, this is only an implementation detail, not the API contract developers can rely on.
Instance methods should not write to static fields
Correctly updating a `static field from a non-static method is tricky to get right and could easily lead to bugs if there are multiple class instances and/or multiple threads in play. Ideally, static fields are only updated from synchronized static methods.
This rule raises an issue each time a static` field is updated from a non-static method.
Non-thread-safe fields should not be static
When an object is marked as static, it means that it belongs to the class rather than any class instance. This means there is only one copy of the static object in memory, regardless of how many class instances are created. Static objects are shared among all instances of the class and can be accessed using the class name rather than an instance of the class.
A data type is considered thread-safe if it can be used correctly by multiple threads, regardless of how those threads are executed, without requiring additional coordination from the calling code. In other words, a thread-safe data type can be accessed and modified by multiple threads simultaneously without causing any issues or requiring extra work from the programmer to ensure correct behavior.
Non-thread-safe objects are objects that are not designed to be used in a multi-threaded environment and can lead to race conditions and data inconsistencies when accessed by multiple threads simultaneously. Using them in a multi-threaded manner is highly likely to cause data problems or exceptions at runtime.
When a non-thread-safe object is marked as static in a multi-threaded environment, it can cause issues because the non-thread-safe object will be shared across different instances of the containing class.
This rule raises an issue when any of the following instances and their subtypes are marked as static:
java.util.Calendar,
java.text.DateFormat,
javax.xml.xpath.XPath, or
javax.xml.validation.SchemaFactory.
Classes should not be compared by name
There is no requirement that class names be unique, only that they be unique within a package. Therefore trying to determine an object’s type based on its class name is an exercise fraught with danger. One of those dangers is that a malicious user will send objects of the same name as the trusted class and thereby gain trusted access.
Instead, the instanceof operator or the Class.isAssignableFrom() method should be used to check the object’s underlying type.
main should have the right signature
”A rose by any other name would smell as sweet,” but main by any other name would not. Just because a method has the name “main”, that doesn’t make it the entry point to an application. It must also have the correct signature. Specifically, it must be public static void and accept a single String [] as an argument.
Modulus results should not be checked for direct equality
When the modulus of a negative number is calculated, the result will either be negative or zero. Thus, comparing the modulus of a variable for equality with a positive number (or a negative one) could result in unexpected results.
Disclosing fingerprints from web application technologies is security-sensitive
Disclosure of version information, usually overlooked by developers but disclosed by default by the systems and frameworks in use, can pose a significant security risk depending on the production environement.
Once this information is public, attackers can use it to identify potential security holes or vulnerabilities specific to that version.
Furthermore, if the published version information indicates the use of outdated or unsupported software, it becomes easier for attackers to exploit known vulnerabilities. They can search for published vulnerabilities related to that version and launch attacks that specifically target those vulnerabilities.
static base class members should not be accessed via derived types
In object-oriented programming, inappropriately accessing static members of a base class via derived types is considered a code smell.
Static members are associated with the class itself, not with any specific instance of the class or its children classes. Accessing through the wrong type suggests a misunderstanding of the ownership and role of this member. This can make the maintenance of the code more complicated.
Therefore, the access should be done directly through the base class to maintain clarity and avoid potential misunderstandings.
@Deprecated code should not be used
Code is sometimes annotated as deprecated by developers maintaining libraries or APIs to indicate that the method, class, or other programming element is no longer recommended for use. This is typically due to the introduction of a newer or more effective alternative. For example, when a better solution has been identified, or when the existing code presents potential errors or security risks.
Deprecation is a good practice because it helps to phase out obsolete code in a controlled manner, without breaking existing software that may still depend on it. It is a way to warn other developers not to use the deprecated element in new code, and to replace it in existing code when possible.
Deprecated classes, interfaces, and their members should not be used, inherited or extended because they will eventually be removed. The deprecation period allows you to make a smooth transition away from the aging, soon-to-be-retired technology.
Check the documentation or the deprecation message to understand why the code was deprecated and what the recommended alternative is.
Allowing user enumeration is security-sensitive
User enumeration refers to the ability to guess existing usernames in a web application database. This can happen, for example, when using “sign-in/sign-on/forgot password” functionalities of a website.
When an user tries to “sign-in” to a website with an incorrect username/login, the web application should not disclose that the username doesn’t exist with a message similar to “this username is incorrect”, instead a generic message should be used like “bad credentials”, this way it’s not possible to guess whether the username or password was incorrect during the authentication.
If a user-management feature discloses information about the existence of a username, attackers can use brute force attacks to retrieve a large amount of valid usernames that will impact the privacy of corresponding users and facilitate other attacks (phishing, password guessing etc …).
Enabling JavaScript support for WebViews is security-sensitive
WebViews can be used to display web content as part of a mobile application. A browser engine is used to render and display the content. Like a web application, a mobile application that uses WebViews can be vulnerable to Cross-Site Scripting if untrusted code is rendered. In the context of a WebView, JavaScript code can exfiltrate local files that might be sensitive or even worse, access exposed functions of the application that can result in more severe vulnerabilities such as code injection. Thus JavaScript support should not be enabled for WebViews unless it is absolutely necessary and the authenticity of the web resources can be guaranteed.
Comments should not be located at the end of lines of code
static members should be accessed statically
While it is possible to access static members from a class instance, it’s bad form, and considered by most to be misleading because it implies to the readers of your code that there’s an instance of the member per class instance.
Using hardcoded IP addresses is security-sensitive
Hardcoding IP addresses is security-sensitive. It has led in the past to the following vulnerabilities:
Today’s services have an ever-changing architecture due to their scaling and redundancy needs. It is a mistake to think that a service will always have the same IP address. When it does change, the hardcoded IP will have to be modified too. This will have an impact on the product development, delivery, and deployment:
The developers will have to do a rapid fix every time this happens, instead of having an operation team change a configuration file.
It misleads to use the same address in every environment (dev, sys, qa, prod).
Last but not least it has an effect on application security. Attackers might be able to decompile the code and thereby discover a potentially sensitive address. They can perform a Denial of Service attack on the service, try to get access to the system, or try to spoof the IP address to bypass security checks. Such attacks can always be possible, but in the case of a hardcoded IP address solving the issue will take more time, which will increase an attack’s impact.
Creating cookies with broadly defined domain flags is security-sensitive
Track uses of TODO tags
Using unencrypted files in mobile applications is security-sensitive
Storing files locally is a common task for mobile applications. Files that are stored unencrypted can be read out and modified by an attacker with physical access to the device. Access to sensitive data can be harmful for the user of the application, for example when the device gets stolen.
Character classes in regular expressions should not contain the same character twice
Character classes in regular expressions are a convenient way to match one of several possible characters by listing the allowed characters or ranges of characters. If the same character is listed twice in the same character class or if the character class contains overlapping ranges, this has no effect.
Thus duplicate characters in a character class are either a simple oversight or a sign that a range in the character class matches more than is intended or that the author misunderstood how character classes work and wanted to match more than one character. A common example of the latter mistake is trying to use a range like [0-99] to match numbers of up to two digits, when in fact it is equivalent to [0-9]. Another common cause is forgetting to escape the - character, creating an unintended range that overlaps with other characters in the character class.
Nested code blocks should not be used
Nested code blocks create new scopes where variables declared within are inaccessible from the outside, and their lifespan ends with the block.
Although this may appear beneficial, their usage within a function often suggests that the function is overloaded. Thus, it may violate the Single Responsibility Principle, and the function needs to be broken down into smaller functions.
The presence of nested blocks that don’t affect the control flow might suggest possible mistakes in the code.
Regex alternatives should not be redundant
If an alternative in a regular expression only matches things that are already matched by another alternative, that alternative is redundant and serves no purpose.
In the best case this means that the offending subpattern is merely redundant and should be removed. In the worst case it’s a sign that this regex does not match what it was intended to match and should be reworked.
Type parameter names should comply with a naming convention
Shared naming conventions make it possible for a team to collaborate efficiently. Following the established convention of single-letter type parameter names helps users and maintainers of your code quickly see the difference between a type parameter and a poorly named class.
This rule check that all type parameter names match a provided regular expression. The following code snippets use the default regular expression.
Field names should comply with a naming convention
A naming convention in software development is a set of guidelines for naming code elements like variables, functions, and classes.
The goal of a naming convention is to make the code more readable and understandable, which makes it easier to maintain and debug. It also ensures consistency in the code, especially when multiple developers are working on the same project.
This rule checks that field names match a provided regular expression.
Unused private methods should be removed
This rule raises an issue when a {visibility} {operationName} is never referenced in the code.
Classes should not be empty
There is no good excuse for an empty class. If it’s being used simply as a common extension point, it should be replaced with an interface. If it was stubbed in as a placeholder for future development it should be fleshed-out. In any other case, it should be eliminated.
Setting loose POSIX file permissions is security-sensitive
In Unix file system permissions, the “others” category refers to all
users except the owner of the file system resource and the members of the group
assigned to this resource.
Granting permissions to this category can lead to unintended access to files or directories that could allow attackers to obtain sensitive information, disrupt services or elevate privileges.
Methods should not return constants
There’s no point in forcing the overhead of a method call for a method that always returns the same constant value. Even worse, the fact that a method call must be made will likely mislead developers who call the method thinking that something more is done. Declare a constant instead.
This rule raises an issue if on methods that contain only one statement: the return of a constant value.
Empty statements should be removed
Empty statements represented by a semicolon ; are statements that do not perform any operation. They are often the result of a typo or a misunderstanding of the language syntax. It is a good practice to remove empty statements since they don’t add value and lead to confusion and errors.
Weak encryption should not be used
Security through obscurity is no security at all, and the use of Base64 encoding to obscure a password will only slow an attacker down for seconds, at the most. Instead, passwords should be encrypted with private keys that are at least 128 bits in length.
This rule checks for the use of Base64 decoding on values that are then used in database and LDAP connections.
Child class fields should not shadow parent class fields
Having a variable with the same name in two unrelated classes is fine, but do the same thing within a class hierarchy and you’ll get confusion at best, chaos at worst.
Switch cases should end with an unconditional break statement
When the execution is not explicitly terminated at the end of a switch case, it continues to execute the statements of the following case. While this is sometimes intentional, it often is a mistake which leads to unexpected behavior.
Equality operators should not be used in for loop termination conditions
Testing for loop termination using an equality operator (== and !=) is dangerous, because it could set up an infinite loop. Using a broader relational operator instead casts a wider net, and makes it harder (but not impossible) to accidentally write an infinite loop.
runFinalizersOnExit should not be called
Enabling runFinalizersOnExit is unsafe as it might result in erratic behavior and deadlocks on application exit.
Indeed, finalizers might be force-called on live objects while other threads are concurrently manipulating them.
Instead, if you want to execute something when the virtual machine begins its shutdown sequence, you should attach a shutdown hook.
Unnecessary imports should be removed
Although they don’t affect the runtime behavior of the application after compilation, removing them will:
Improve the readability and maintainability of the code.
Help avoid potential naming conflicts.
Improve the build time, as the compiler has fewer lines to read and fewer types to resolve.
Reduce the number of items the code editor will show for auto-completion, thereby showing fewer irrelevant suggestions.
Files should not be empty
Files with no lines of code clutter a project and should be removed.
Using weak hashing algorithms is security-sensitive
Cryptographic hash algorithms such as MD2, MD4, MD5, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160 and SHA-1 are no longer considered secure, because it is possible to have collisions (little computational effort is enough to find two or more different inputs that produce the same hash).
The ternary operator should not be used
Ternary expressions, while concise, can often lead to code that is difficult to read and understand, especially when they are nested or complex. Prioritizing readability fosters maintainability and reduces the likelihood of bugs. Therefore, they should be removed in favor of more explicit control structures, such as if/else statements, to improve the clarity and readability of the code.
Derived exceptions should not hide their parents catch blocks
The `catch block of a checked exception “E” may be hidden because the corresponding try block only throws exceptions derived from E.
These derived exceptions are handled in dedicated catch blocks prior to the catch block of the base exception E.
The catch` block of E is unreachable and should be considered dead code. It should be removed, or the entire try-catch structure should be refactored.
It is also possible that a single exception type in a multi-catch block may be hidden while the catch block itself is still reachable. In that case it is enough to only remove the hidden exception type or to replace it with another type.
Regex patterns following a possessive quantifier should not always fail
Possessive quantifiers in Regex patterns like below improve performance by eliminating needless backtracking:
?+ , *+ , ++ , {n}+ , {n,}+ , {n,m}+But because possessive quantifiers do not keep backtracking positions and never give back, the following sub-patterns should not match only similar characters. Otherwise, possessive quantifiers consume all characters that could have matched the following sub-patterns and nothing remains for the following sub-patterns.
Zip function calls should not be vulnerable to path traversal attacks
Libraries used to unarchive a file (zip, bzip2, tar, …) do what they were made for: they extract the content of the archive blindly, creating on the filesystem directories and files corresponding exactly to the content of the archive. Using a specially crafted archive containing some path traversal filenames, it is possible to create directories/files outside of the dir where the archive is extracted. This can lead to overwriting an executable or a configuration file with a file containing malicious code and transform a simple archive into a way to execute arbitrary code.
Regular expressions should not contain empty groups
There are several reasons to use a group in a regular expression:
to change the precedence (e.g. do(g|or) will match ‘dog’ and ‘door’)
to remember parenthesised part of the match in the case of capturing group
to improve readability
In any case, having an empty group is most probably a mistake. Either it is a leftover after refactoring and should be removed, or the actual parentheses were intended and were not escaped.
Using non-standard cryptographic algorithms is security-sensitive
The use of a non-standard algorithm is dangerous because a determined attacker may be able to break the algorithm and compromise whatever data has been protected. Standard algorithms like `SHA-256, SHA-384, SHA-512, … should be used instead.
This rule tracks creation of java.security.MessageDigest` subclasses.
switch statements should have default clauses
The requirement for a final default clause is defensive programming. The clause should either take appropriate action, or contain a suitable comment as to why no action is taken.
Duplicate values should not be passed as arguments
There are valid cases for passing a variable multiple times into the same method call, but usually doing so is a mistake, and something else was intended for one of the arguments.
Broadcasting intents is security-sensitive
In Android applications, broadcasting intents is security-sensitive. For example, it has led in the past to the following vulnerability:
By default, broadcasted intents are visible to every application, exposing all sensitive information they contain.
This rule raises an issue when an intent is broadcasted without specifying any “receiver permission”.
Authorizing non-authenticated users to use keys in the Android KeyStore is security-sensitive
XML parsers should not load external schemas
By default XML processors attempt to load all XML schemas and DTD (their locations are defined with xsi:schemaLocation attributes and DOCTYPE declarations), potentially from an external storage such as file system or network, which may lead, if no restrictions are put in place, to server-side request forgery (SSRF) vulnerabilities.
Disabling content security policy fetch directives is security-sensitive
Content security policy (CSP) (fetch directives) is a W3C standard which is used by a server to specify, via a http header, the origins from where the browser is allowed to load resources. It can help to mitigate the risk of cross site scripting (XSS) attacks and reduce privileges used by an application. If the website doesn’t define CSP header the browser will apply same-origin policy by default.
Content-Security-Policy: default-src ‘self’; script-src ‘self ‘ http://www.example.com
In the above example, all resources are allowed from the website where this header is set and script resources fetched from example.com are also authorized:
<img src=“selfhostedimage.png></script> <!— will be loaded because default-src ‘self’; directive is applied —> <img src=“http://www.example.com/image.png></script> <!— will NOT be loaded because default-src ‘self’; directive is applied —> <script src=“http://www.example.com/library.js></script> <!— will be loaded because script-src ‘self ‘ http://www.example.comdirective is applied —> <script src=“selfhostedscript.js></script> <!— will be loaded because script-src ‘self ‘ http://www.example.com directive is applied —> <script src=“http://www.otherexample.com/library.js></script> <!— will NOT be loaded because script-src ‘self ‘ http://www.example.comdirective is applied —>
Unused local variables should be removed
An unused local variable is a variable that has been declared but is not used anywhere in the block of code where it is defined. It is dead code, contributing to unnecessary complexity and leading to confusion when reading the code. Therefore, it should be removed from your code to maintain clarity and efficiency.
Passwords should not be stored in plaintext or with a fast hashing algorithm
Attackers who would get access to the stored passwords could reuse them without further attacks or with little additional effort. Obtaining the plaintext passwords, they could then gain unauthorized access to user accounts, potentially leading to various malicious activities.
Unused assignments should be removed
Dead stores refer to assignments made to local variables that are subsequently never used or immediately overwritten. Such assignments are unnecessary and don’t contribute to the functionality or clarity of the code. They may even negatively impact performance. Removing them enhances code cleanliness and readability. Even if the unnecessary operations do not do any harm in terms of the program’s correctness, they are - at best - a waste of computing resources.
Cognitive Complexity of methods should not be too high
Cognitive Complexity is a measure of how hard it is to understand the control flow of a unit of code. Code with high cognitive complexity is hard to read, understand, test, and modify.
As a rule of thumb, high cognitive complexity is a sign that the code should be refactored into smaller, easier-to-manage pieces.
Unread private fields should be removed
Private fields which are written but never read are a case of “dead store”. Changing the value of such a field is useless and most probably indicates an error in the code.
Source code should be indented consistently
Consistent indentation is a simple and effective way to improve the code’s readability. It reduces the differences that are committed to source control systems, making code reviews easier.
This rule raises an issue when the indentation does not match the configured value. Only the first line of a badly indented section is reported.
Boolean expressions should not be gratuitous
Control flow constructs like if-statements allow the programmer to direct the flow of a program depending on a boolean expression. However, if the condition is always true or always false, only one of the branches will ever be executed. In that case, the control flow construct and the condition no longer serve a purpose; they become gratuitous.
Local variable and method parameter names should comply with a naming convention
A naming convention in software development is a set of guidelines for naming code elements like variables, functions, and classes. {identifier_capital_plural} hold the meaning of the written code. Their names should be meaningful and follow a consistent and easily recognizable pattern. Adhering to a consistent naming convention helps to make the code more readable and understandable, which makes it easier to maintain and debug. It also ensures consistency in the code, especially when multiple developers are working on the same project.
This rule checks that {identifier} names match a provided regular expression.
Public types, methods and fields (API) should be documented with Javadoc
Undocumented APIs pose significant challenges in software development for several reasons:
Lack of Clarity: developers struggling to understand how to use the API correctly. This can lead to misuse and unexpected results.
Increased Development Time: developers spending extra time reading and understanding the source code, which slows down the development process.
Error Prone: developers are more likely to make mistakes that lead to bugs or system crashes when the intent or the error handling of an API is not clear.
Difficult Maintenance and Updates: developers may not understand the existing functionality well enough to add new features without breaking the existing ones.
Poor Collaboration: collaboration, when there is lack of documentation, leads to confusion and inconsistencies.
Enumeration should not be implemented
”Enumeration” should not be implemented
Local variables should not shadow class fields
Local variables should not shadow class fields
Calls to methods should not trigger an exception
Calls to methods should not trigger an exception
AWS region should not be set with a hardcoded String
AWS region should not be set with a hardcoded String
Week Year (YYYY) should not be used for date formatting
Week Year (“YYYY”) should not be used for date formatting
This is a rule showcasing images in rules
This is a rule showcasing images in rules
Packages should have a javadoc file package-info.java
Packages should have a javadoc file ‘package-info.java’
Javadoc tags should not be used in non-Javadoc comments
equals method parameters should not be marked @Nonnull
”equals” method parameters should not be marked “@Nonnull"
@Bean methods for Singleton should not be invoked in @Configuration when proxyBeanMethods is false
"@Bean” methods for Singleton should not be invoked in “@Configuration” when proxyBeanMethods is false
Accessing an array element should not trigger an ArrayIndexOutOfBoundsException
Accessing an array element should not trigger an ArrayIndexOutOfBoundsException
Classes that override clone should be Cloneable and call super.clone()
Classes that override “clone” should be “Cloneable” and call “super.clone()"
enum.ordinal should not be called
"enum.ordinal” should not be called
@Deprecated code marked for removal should never be used
”@Deprecated” code marked for removal should never be used
This rule verifies that single-line comments are not located at the ends of lines of code. The main idea behind this rule is that in order to be really readable, trailing comments would have to be properly written and formatted (correct alignment, no interference with the visual structure of the code, not too long to be visible) but most often, automatic code formatters would not handle this correctly: the code would end up less readable. Comments are far better placed on the previous empty line of code, where they will always be visible and properly formatted.