From 4de9f9f8e864a3564e6f2fe316424ec80280e5a4 Mon Sep 17 00:00:00 2001
From: simonbrandhof
Property ignoreLines specifies the line numbers to ignore when matching lines in a header file. This property is very useful for supporting headers that contain copyright dates. For example, consider the following header:
@@ -26,7 +26,7 @@- + Checks the header of a source file against a header that contains a regular expression for each line of the source header. Rationale: In some projects checking against a fixed header is not sufficient, e.g. the header might require a copyright line where the year information is not static. For example, consider the following header:
@@ -68,7 +68,7 @@- + @@ -84,7 +84,7 @@ @@ -92,7 +92,7 @@ - + - + @@ -104,7 +104,7 @@ - + This check makes sure that all package annotations are in the package-info.java file. @@ -113,7 +113,7 @@According to the Java JLS 3rd ed.
The JLS does not enforce the placement of package annotations. This placement may vary based on implementation. The JLS does highly recommend that all package annotations are placed in the package-info.java file. See Java Language specification, sections 7.4.1.1.
]]>- + This check allows you to specify what warnings that SuppressWarnings is not allowed to suppress. You can also specify a list of TokenTypes that the configured warning(s) cannot be suppressed on. Limitations: This check does not consider conditionals inside the SuppressWarnings annotation. @@ -131,7 +131,7 @@ For example: @SupressWarnings((false) ? (true) ? "unchecked" : "foo" : "unused")
- + Checks that any combination of String literals with optional assignment is on the left side of an equals() comparison. Rationale: Calling the equals() method on String literals will avoid a potential NullPointerException. Also, it is pretty common to see null check right before equals comparisons which is not necessary in the below example.
@@ -164,7 +164,7 @@ should be refactored to:- + Checks that the clone method is not overridden from the Object class. Rationale: The clone method relies on strange/hard to follow rules that do not work it all situations. Consequently, it is difficult to override correctly. Below are some of the rules/reasons why the clone method should be avoided. @@ -210,14 +210,14 @@ should be refactored to:
]]>- + Verifies there are no finalize() methods defined in a class. - + Checks that there are no static import statements. Rationale: Importing static members can lead to naming conflicts between class' members. It may lead to poor code readability since it may no longer be clear what class a member resides in (without looking at the import statement).]]> @@ -230,7 +230,7 @@ For example: Excluding java.lang.Math.*. will allow the import of each static me - + Checks that each Java package has a Javadoc file used for commenting. By default it only allows a package-info.java file, but can be configured to allow a package.html file. An error will be reported if both files exist as this is not allowed by the Javadoc tool.]]> @@ -241,7 +241,7 @@ For example: Excluding java.lang.Math.*. will allow the import of each static me - + MULTIPLE A check for detecting that matches across multiple lines. Rationale: This check can be used to when the regular expression can be span multiple lines.]]> @@ -264,7 +264,7 @@ For example: Excluding java.lang.Math.*. will allow the import of each static me- + A check for detecting single lines that match a supplied regular expression. Works with any file type. Rationale: This check can be used to prototype checks and to find common bad practice such as calling ex.printStacktrace(), System.out.println(), System.exit(), etc.]]> MULTIPLE @@ -287,7 +287,7 @@ For example: Excluding java.lang.Math.*. will allow the import of each static me- + This class is variation on RegexpSingleline for detecting single lines that match a supplied regular expression in Java files. It supports suppressing matches in Java comments.]]> MULTIPLE @@ -313,7 +313,7 @@ For example: Excluding java.lang.Math.*. will allow the import of each static me- + Checks for the number of types declared at the outer (or root) level in a file. Rationale: It is considered good practice to only define one outer type per file.]]> @@ -323,7 +323,7 @@ For example: Excluding java.lang.Math.*. will allow the import of each static me - + Checks that there are no tab characters ('\t') in the source code. Rationale: ]]>
- Developers should not need to configure the tab width of their text editors in order to be able to read source code.
@@ -337,7 +337,7 @@ For example: Excluding java.lang.Math.*. will allow the import of each static me- + Checks that the whitespace around the Generic tokens < and > is correct to the typical convention. The convention is not configurable. For example the following is legal: @@ -362,7 +362,7 @@ But the following example is not:
- + - + - It is a duplicate of another import. This is, when a class is imported more than once.
@@ -398,7 +398,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain- + @@ -409,7 +409,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -418,13 +418,13 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + @@ -435,13 +435,13 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + @@ -450,7 +450,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -460,7 +460,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -474,7 +474,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -484,7 +484,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -493,7 +493,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -504,14 +504,14 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + @@ -521,33 +521,33 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - Class (static) variables. First the public class variables, then the protected, then package level (no access modifier), and then the private.
- Instance variables. First the public class variables, then the protected, then package level (no access modifier), and then the private.
- Constructors
- Methods
- + - + - + - + @@ -560,7 +560,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + for ( ; i < j; i++, j--)]]> @@ -570,7 +570,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain- + for (Iterator foo = very.long.line.iterator(); foo.hasNext(); )]]> @@ -580,19 +580,19 @@ Rationale: Too large methods and classes are hard to read and costly to maintain- + - + - + @@ -606,14 +606,14 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + @@ -628,7 +628,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + Checks for long source files. @@ -638,13 +638,13 @@ Rationale: Too large methods and classes are hard to read and costly to maintainRationale: If a source file becomes very long it is hard to understand. Therefore long classes should usually be refactored into several individual classes that focus on a specific task.
]]>- + - + @@ -654,7 +654,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -664,7 +664,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -690,14 +690,14 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + @@ -707,7 +707,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -716,7 +716,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + java.lang.Boolean class. In order to save memory and CPU cycles, it is preferable to use the predefined constants TRUE and FALSE. Constructor invocations should be replaced by calls to @@ -726,7 +726,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintainBoolean.valueOf()
. Some extremely performance sensitive projects may require the use of factory methods for other classes as well, to enforce the usage of number caches or object pools.]]>- + @@ -736,7 +736,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -746,7 +746,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + MULTIPLE @@ -766,7 +766,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -789,7 +789,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + groups imports: ensures that groups of imports come in a specific order (e.g., java. comes first, javax. comes second, then everything else) adds a separation between groups : ensures that a blank line sit between each group @@ -822,7 +822,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain- + @@ -838,7 +838,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + @@ -861,7 +861,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + Ensures the first sentence ends with proper punctuation (That is a period, question mark, or exclamation mark, by default). @@ -968,7 +968,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + @@ -1008,7 +1008,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + eol and @@ -1027,7 +1027,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintainnlow
take into account property maxLineLength.]]>- + @@ -1044,7 +1044,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1055,7 +1055,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1070,7 +1070,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1082,7 +1082,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1105,7 +1105,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1121,7 +1121,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1131,7 +1131,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1148,27 +1148,27 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + - + @@ -1176,7 +1176,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + MULTIPLE -+ @@ -1194,14 +1194,14 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + @@ -1212,7 +1212,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1223,7 +1223,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1232,7 +1232,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1241,7 +1241,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1250,7 +1250,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1265,7 +1265,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1279,7 +1279,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1292,7 +1292,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1307,14 +1307,14 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + @@ -1325,13 +1325,13 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + @@ -1342,7 +1342,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1356,7 +1356,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1369,7 +1369,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1378,7 +1378,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1393,7 +1393,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + MULTIPLE @@ -1424,7 +1424,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1437,7 +1437,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1449,7 +1449,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1463,19 +1463,19 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + - + @@ -1485,7 +1485,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1498,25 +1498,25 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + - + - + @@ -1525,7 +1525,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + MULTIPLE @@ -1535,7 +1535,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1552,7 +1552,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1565,7 +1565,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1578,7 +1578,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1592,7 +1592,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1603,26 +1603,26 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + - + - + Section 3.10.1.]]> - + @@ -1639,7 +1639,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1649,7 +1649,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + @@ -1667,7 +1667,7 @@ Rationale: Too large methods and classes are hard to read and costly to maintain - + diff --git a/plugins/sonar-findbugs-plugin/src/main/resources/org/sonar/plugins/findbugs/rules.xml b/plugins/sonar-findbugs-plugin/src/main/resources/org/sonar/plugins/findbugs/rules.xml index 909109f919c..577575cd2c5 100644 --- a/plugins/sonar-findbugs-plugin/src/main/resources/org/sonar/plugins/findbugs/rules.xml +++ b/plugins/sonar-findbugs-plugin/src/main/resources/org/sonar/plugins/findbugs/rules.xml @@ -3,14 +3,14 @@ - + - + This code is casting the result of calling toArray() on a collection to a type more specific than Object[], as in: String[] getAsArray(Collectionpublic static void initLogging() throws Exception { @@ -61,7 +61,7 @@c) { @@ -24,21 +24,21 @@ - + - + - + OpenJDK introduces a potential incompatibility. In particular, the java.util.logging.Logger behavior has changed. Instead of using strong references, it now uses weak references internally. That's a reasonable change, but unfortunately some code relies on the old behavior - when changing logger configuration, it simply drops the logger reference. That means that the garbage collector is free to reclaim that memory, which means that the logger configuration is lost. For example, consider: @@ -69,7 +69,7 @@ - + @@ -77,7 +77,7 @@ - + @@ -85,7 +85,7 @@ - + @@ -93,7 +93,7 @@ - + @@ -101,7 +101,7 @@ - + - + This method is invoked in the constructor of of the superclass. At this point, the fields of the class have not yet initialized. To make this more concrete, consider the following classes: abstract class A { @@ -127,7 +127,7 @@@@ -137,32 +137,32 @@ - + - + This field is never initialized within any constructor, and is therefore could be null after the object is constructed. This could be a either an error or a questionable design, since it means a null pointer exception will be generated if that field is dereferenced before being initialized.]]> - + The program is dereferencing a field that does not seem to ever have a non-null value written to it. Dereferencing this value will generate a null pointer exception.]]> - + This field is never written. All reads of it will return the default value. Check for errors (should it have been initialized?), or remove it if it is useless.]]> - + This class is bigger than can be effectively handled, and was not fully analyzed for errors. ]]> - + (Javadoc) A ScheduledThreadPoolExecutor with zero core threads will never execute anything; changes to the max pool size are ignored. ]]> @@ -170,7 +170,7 @@ A ScheduledThreadPoolExecutor with zero core threads will never execute anything- + (Javadoc) While ScheduledThreadPoolExecutor inherits from ThreadPoolExecutor, a few of the inherited tuning methods are not useful for it. In particular, because it acts as a fixed-sized pool using corePoolSize threads and an unbounded queue, adjustments to maximumPoolSize have no useful effect. ]]> @@ -178,21 +178,21 @@ While ScheduledThreadPoolExecutor inherits from ThreadPoolExecutor, a few of the- + All targets of this method invocation throw an UnsupportedOperationException. ]]> - + This code creates a database connect using a blank or empty password. This indicates that the database is not protected by a password. ]]> - + This code creates a database connect using a hardcoded, constant password. Anyone with access to either the source code or the compiled code can easily learn the password. ]]> @@ -200,7 +200,7 @@ While ScheduledThreadPoolExecutor inherits from ThreadPoolExecutor, a few of the- + This code constructs an HTTP Cookie using an untrusted HTTP parameter. If this cookie is added to an HTTP response, it will allow a HTTP response splitting vulnerability. See http://en.wikipedia.org/wiki/HTTP_response_splitting for more information. @@ -213,7 +213,7 @@ consider using a commercial static analysis or pen-testing tool. - + This code directly writes an HTTP parameter to an HTTP header, which allows for a HTTP response splitting vulnerability. See http://en.wikipedia.org/wiki/HTTP_response_splitting for more information. @@ -226,7 +226,7 @@ consider using a commercial static analysis or pen-testing tool. - + This code directly writes an HTTP parameter to Servlet output, which allows for a reflected cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information. @@ -239,7 +239,7 @@ consider using a commercial static analysis or pen-testing tool. - + This code directly writes an HTTP parameter to a Server error page (using HttpServletResponse.sendError). Echoing this untrusted input allows for a reflected cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting @@ -253,7 +253,7 @@ consider using a commercial static analysis or pen-testing tool. - + This code directly writes an HTTP parameter to JSP output, which allows for a cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information. @@ -266,7 +266,7 @@ consider using a commercial static analysis or pen-testing tool. - + (From JDC Tech Tip): The Swing methods show(), setVisible(), and pack() will create the associated peer for the frame. With the creation of the peer, the system creates the event dispatch thread. @@ -280,21 +280,21 @@ visible), they could trigger listener notification on the event dispatch thread. - + This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).]]> - + This method unconditionally invokes itself. This would seem to indicate an infinite recursive loop that will result in a stack overflow.]]> - + A collection is added to itself. As a result, computing the hashCode of this set will throw a StackOverflowException. ]]> @@ -303,7 +303,7 @@ set will throw a StackOverflowException.- + This declares a volatile reference to an array, which might not be what you want. With a volatile reference to an array, reads and writes of the reference to the array are treated as volatile, but the array elements @@ -314,7 +314,7 @@ in Java 5.0).]]> - + Calling @@ -322,7 +322,7 @@ another package.]]>this.getClass().getResource(...)
could give results other than expected if this class is extended by a class in another package.]]>- + A method that returns either Boolean.TRUE, Boolean.FALSE or null is an accident waiting to happen. This method can be invoked as though it returned a value of type boolean, and @@ -333,7 +333,7 @@ another package.]]> - + Since the field is synchronized on, it seems not likely to be null. If it is null and then synchronized on a NullPointerException will be thrown and the check would be pointless. Better to synchronize on @@ -342,7 +342,7 @@ another field.]]> - + The code contains a conditional test is performed twice, one right after the other (e.g., x == 0 || x == 0
). Perhaps the second occurrence is intended to be something else (e.g.,x == 0 || y == 0
). @@ -351,7 +351,7 @@ another field.]]>- + The code calls putNextEntry()
, immediately followed by a call tocloseEntry()
. This results in an empty ZipFile entry. The contents of the entry @@ -362,7 +362,7 @@ should be written to the ZipFile between the calls to- + The code calls putNextEntry()
, immediately followed by a call tocloseEntry()
. This results in an empty JarFile entry. The contents of the entry @@ -373,7 +373,7 @@ should be written to the JarFile between the calls to- + IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on).]]> @@ -381,7 +381,7 @@ should be written to the JarFile between the calls to- + The method performs math operations using floating point precision. Floating point precision is very imprecise. For example, @@ -390,7 +390,7 @@ should be written to the JarFile between the calls to - + Class implements Cloneable but does not define or use the clone method.]]> @@ -398,7 +398,7 @@ should be written to the JarFile between the calls to- + This class defines a clone() method but the class doesn't implement Cloneable. There are some situations in which this is OK (e.g., you want to control how subclasses can clone themselves), but just make sure that this is what you intended. @@ -407,7 +407,7 @@ can clone themselves), but just make sure that this is what you intended. - + This non-final class defines a clone() method that does not call super.clone(). If this class ("A") is extended by a subclass ("B"), and the subclass B calls super.clone(), then it is likely that @@ -420,14 +420,14 @@ to use Object.clone(), which always returns an object of the correct type.]] - + The identifier is a word that is reserved as a keyword in later versions of Java, and your code will need to be changed in order to compile it in later versions of Java.]]> - + This identifier is used as a keyword in later versions of Java. This code, and any code that references this API, will need to be changed in order to compile it in later versions of Java.]]> @@ -435,7 +435,7 @@ will need to be changed in order to compile it in later versions of Java.]]>- + This method might drop an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.]]> @@ -443,7 +443,7 @@ will need to be changed in order to compile it in later versions of Java.]]>- + This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method.]]> @@ -451,7 +451,7 @@ will need to be changed in order to compile it in later versions of Java.]]>- + This code invokes a method that requires a security permission check. If this code will be granted security permissions, but might be invoked by code that does not have security permissions, then the invocation needs to occur inside a doPrivileged block.]]> @@ -459,7 +459,7 @@ will need to be changed in order to compile it in later versions of Java.]]>- + This code creates a classloader, which requires a security manager. If this code will be granted security permissions, but might be invoked by code that does not have security permissions, then the classloader creation needs to occur inside a doPrivileged block.]]> @@ -467,7 +467,7 @@ will need to be changed in order to compile it in later versions of Java.]]>- + The class is annotated with net.jcip.annotations.Immutable, and the rules for that annotation require that all fields are final. .]]> @@ -475,7 +475,7 @@ that all fields are final.- + A Thread object is passed as a parameter to a method where a Runnable is expected. This is rather unusual, and may indicate a logic error or cause unexpected behavior. @@ -484,7 +484,7 @@ or cause unexpected behavior. - + This method or field is or uses a Map or Set of URLs. Since both the equals and hashCode method of URL perform domain name resolution, this can result in a big performance hit. See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information. @@ -494,7 +494,7 @@ Consider using java.net.URI
instead.- + The equals and hashCode method of URL perform domain name resolution, this can result in a big performance hit. See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html for more information. @@ -505,7 +505,7 @@ Consider using java.net.URI
instead.- + Unless an annotation has itself been annotated with @Retention(RetentionPolicy.RUNTIME), the annotation can't be observed using reflection (e.g., by using the isAnnotationPresent method). .]]> @@ -513,7 +513,7 @@ Consider usingjava.net.URI
instead.- + Invoking System.exit shuts down the entire Java virtual machine. This should only been done when it is appropriate. Such calls make it hard or impossible for your code to be invoked by other code. @@ -522,7 +522,7 @@ Consider using java.net.URI
instead.- + Never call System.runFinalizersOnExit or Runtime.runFinalizersOnExit for any reason: they are among the most dangerous methods in the Java libraries. -- Joshua Bloch]]> @@ -530,7 +530,7 @@ dangerous methods in the Java libraries. -- Joshua Bloch]]>- + Using the java.lang.String(String)
constructor wastes memory because the object so constructed will be functionally indistinguishable from theString
passed as a parameter. Just use the @@ -539,7 +539,7 @@ dangerous methods in the Java libraries. -- Joshua Bloch]]>- + Creating a new java.lang.String
object using the no-argument constructor wastes memory because the object so created will be functionally indistinguishable from the empty string constant @@ -550,14 +550,14 @@ dangerous methods in the Java libraries. -- Joshua Bloch]]>- + Calling String.toString()
is just a redundant operation. Just use the String.]]>- + Code explicitly invokes garbage collection. Except for specific use in benchmarking, this is very dubious. In the past, situations where people have explicitly invoked @@ -570,7 +570,7 @@ dangerous methods in the Java libraries. -- Joshua Bloch
]]>- + Creating new instances of java.lang.Boolean
wastes memory, sinceBoolean
objects are immutable and there are only two useful values of this type. Use theBoolean.valueOf()
@@ -579,7 +579,7 @@ dangerous methods in the Java libraries. -- Joshua Bloch]]>- + Using new Integer(int)
is guaranteed to always result in a new object whereasInteger.valueOf(int)
allows caching of values to be done by the compiler, class library, or JVM. @@ -600,7 +600,7 @@ dangerous methods in the Java libraries. -- Joshua Bloch]]>- + Using new Double(double)
is guaranteed to always result in a new object whereasDouble.valueOf(double)
allows caching of values to be done by the compiler, class library, or JVM. @@ -614,7 +614,7 @@ dangerous methods in the Java libraries. -- Joshua Bloch]]>- + A String is being converted to upper or lowercase, using the platform's default encoding. This may result in improper conversions when used with international characters. Use the @@ -623,7 +623,7 @@ dangerous methods in the Java libraries. -- Joshua Bloch]]>
String.toUpperCase( Locale l ) String.toLowerCase( Locale l ) - + A wrapped primitive value is unboxed and converted to another primitive type as part of the evaluation of a conditional ternary operator (the b ? e1 : e2
operator). The semantics of Java mandate that ife1
ande2
are wrapped @@ -636,7 +636,7 @@ converted to a floating point value, and boxed. See JLS Section 15.25.- + A primitive is boxed, and then immediately unboxed. This probably is due to a manual boxing in a place where an unboxed value is required, thus forcing the compiler to immediately undo the work of the boxing. @@ -645,14 +645,14 @@ to immediately undo the work of the boxing. - + A primitive boxed value constructed and then immediately converted into a different primitive type (e.g., new Double(d).intValue()
). Just perform direct primitive coercion (e.g.,(int) d
).]]>- + A boxed primitive is allocated just to call toString(). It is more effective to just use the static form of toString which takes the primitive value. So, @@ -669,14 +669,14 @@ to immediately undo the work of the boxing.
- + This method allocates an object just to call getClass() on it, in order to retrieve the Class object for it. It is simpler to just access the .class property of the class.]]> - + This method calls wait()
on ajava.util.concurrent.locks.Condition
object. @@ -687,7 +687,7 @@ to immediately undo the work of the boxing.- + A random value from 0 to 1 is being coerced to the integer value 0. You probably want to multiple the random value by something else before coercing it to an integer, or use the @@ -696,7 +696,7 @@ want to multiple the random value by something else before coercing it to an intRandom.nextInt(n)
method. ]]>- + If @@ -704,7 +704,7 @@ usingr
is ajava.util.Random
, you can generate a random number from0
ton-1
usingr.nextInt(n)
, rather than using(int)(r.nextDouble() * n)
. ]]>r.nextInt(n)
, rather than using(int)(r.nextDouble() *
- + The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to @@ -714,7 +714,7 @@ SQL injection attacks. - + The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable. @@ -723,7 +723,7 @@ be used to make the prepared statement do something unexpected and undesirable. - + This method creates a thread without specifying a run method either by deriving from the Thread class, or by passing a Runnable object. This thread, then, does nothing but waste time. ]]> @@ -731,7 +731,7 @@ be used to make the prepared statement do something unexpected and undesirable.- + This method may contain an instance of double-checked locking. This idiom is not correct according to the semantics of the Java memory model. For more information, see the web page @@ -741,14 +741,14 @@ be used to make the prepared statement do something unexpected and undesirable. - + This finalizer nulls out fields. This is usually an error, as it does not aid garbage collection, and the object is going to be garbage collected anyway.]]> - + This finalizer does nothing except null out fields. This is completely pointless, and requires that the object be garbage collected, finalized, and then garbage collected again. You should just remove the finalize method.]]> @@ -756,21 +756,21 @@ method.]]>- + A class's finalize()
method should have protected access, not public.]]>- + Empty finalize()
methods are useless, so they should be deleted.]]>- + This empty finalize()
method explicitly negates the effect of any finalizer defined by its superclass. Any finalizer actions defined for the superclass will not be performed. @@ -779,7 +779,7 @@ method.]]>- + The only thing this @@ -787,7 +787,7 @@ method.]]>finalize()
method does is call the superclass'sfinalize()
method, making it redundant. Delete it.]]>- + This finalize()
method does not make a call to its superclass'sfinalize()
method. So, any finalizer actions defined for the superclass will not be performed. @@ -796,7 +796,7 @@ method.]]>- + This method contains an explicit invocation of the finalize()
method on an object. Because finalizer methods are supposed to be executed once, and only by the VM, this is a bad idea. @@ -808,7 +808,7 @@ on objects referenced by X, because they may already be getting finalized in a s- + This equals method is checking to see if the argument is some incompatible type (i.e., a class that is neither a supertype nor subtype of the class that defines the equals method). For example, the Foo class might have an equals method @@ -830,7 +830,7 @@ is symmetric and transitive. Without those properties, very unexpected behavoirs - + This class defines an enumeration, and equality on enumerations are defined using object identity. Defining a covariant equals method for an enumeration value is exceptionally bad practice, since it would likely result @@ -842,7 +842,7 @@ Don't do it. - + This class defines a covariant version of the equals()
method, but inherits the normalequals(Object)
method defined in the basejava.lang.Object
class. @@ -852,7 +852,7 @@ Don't do it.- + This class defines an equals()
method, that doesn't override the normalequals(Object)
method defined in the basejava.lang.Object
class. @@ -862,7 +862,7 @@ Don't do it.- + This class defines an equals()
method, that doesn't override the normalequals(Object)
method defined in the basejava.lang.Object
class. Instead, it @@ -875,7 +875,7 @@ Don't do it.- + This class extends a class that defines an equals method and adds fields, but doesn't define an equals method itself. Thus, equality on instances of this class will ignore the identity of the subclass and the added fields. Be sure this is what is intended, @@ -888,7 +888,7 @@ invoking super.equals(o). - + This class defines a covariant version of equals()
. To correctly override theequals()
method injava.lang.Object
, the parameter ofequals()
@@ -897,7 +897,7 @@ invoking super.equals(o).- + This class defines an equals method that overrides an equals method in a superclass. Both equals methods methods use instanceof
in the determination of whether two objects are equal. This is fraught with peril, since it is important that the equals method is symmetrical (in other words,a.equals(b) == b.equals(a)
). @@ -909,7 +909,7 @@ methods is not symmetric.- + This class has an equals method that will be broken if it is inherited by subclasses. It compares a class literal with the class of the argument (e.g., in class Foo
it might check ifFoo.class == o.getClass()
). @@ -919,7 +919,7 @@ It is better to check ifthis.getClass() == o.getClass()
.- + This class doesn't do any of the patterns we recognize for checking that the type of the argument is compatible with the type of the this
object. There might not be anything wrong with this code, but it is worth reviewing. @@ -928,7 +928,7 @@ this code, but it is worth reviewing.- + This method checks to see if two objects are the same class by checking to see if the names of their classes are equal. You can have different classes with the same name if they are loaded by different class loaders. Just check to see if the class objects are the same. @@ -937,7 +937,7 @@ different class loaders. Just check to see if the class objects are the same. - + This class defines an equals method that always returns true. This is imaginative, but not very smart. Plus, it means that the equals method is not symmetric. ]]> @@ -945,7 +945,7 @@ Plus, it means that the equals method is not symmetric.- + This class defines an equals method that always returns false. This means that an object is not equal to itself, and it is impossible to create useful Maps or Sets of this class. More fundamentally, it means that equals is not reflexive, one of the requirements of the equals method. The likely intended semantics are object identity: that an object is equal to itself. This is the behavior inherited from class
Object
. If you need to override an equals inherited from a different @@ -958,7 +958,7 @@ public boolean equals(Object o) { return this == o; }- + A large String constant is duplicated across multiple class files. This is likely because a final field is initialized to a String constant, and the Java language @@ -971,7 +971,7 @@ that classfile. See - + A parameter to this method has been identified as a value that should always be checked to see whether or not it is null, but it is being dereferenced @@ -981,7 +981,7 @@ that classfile. See - + This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null @@ -992,7 +992,7 @@ that classfile. See - + This class defines a covariant version of compareTo()
. To correctly override thecompareTo()
method in theComparable
interface, the parameter ofcompareTo()
@@ -1001,7 +1001,7 @@ that classfile. See- + A method, field or class declares a generic signature where a non-hashable class is used in context where a hashable class is required. A class that declares an equals method but inherits a hashCode() method @@ -1012,7 +1012,7 @@ equal objects have equal hashCodes. - + A class defines an equals(Object) method but not a hashCode() method, and thus doesn't fulfill the requirement that equal objects have equal hashCodes. An instance of this class is used in a hash data structure, making the need to @@ -1021,7 +1021,7 @@ fix this problem of highest importance.]]> - + This class defines a hashCode()
method but inherits itsequals()
method fromjava.lang.Object
(which defines equality by comparing object references). Although @@ -1040,7 +1040,7 @@ the recommendedhashCode
implementation to use is:- + This class defines a compareTo(...)
method but inherits itsequals()
method fromjava.lang.Object
. Generally, the value of compareTo should return zero if and only if @@ -1060,7 +1060,7 @@ is "Note: this class has a natural ordering that is inconsistent with equals."- + This class defines a @@ -1068,7 +1068,7 @@ is "Note: this class has a natural ordering that is inconsistent with equals."hashCode()
method but not anequals()
method. Therefore, the class may violate the invariant that equal objects must have equal hashcodes.]]>- + This class overrides equals(Object)
, but does not overridehashCode()
, and inherits the implementation ofhashCode()
fromjava.lang.Object
(which returns @@ -1086,7 +1086,7 @@ the recommendedhashCode
implementation to use is:- + This class inherits equals(Object)
from an abstract superclass, andhashCode()
fromjava.lang.Object
(which returns @@ -1102,7 +1102,7 @@ the recommendedhashCode
implementation to use is:- + This class overrides @@ -1110,7 +1110,7 @@ the recommendedequals(Object)
, but does not overridehashCode()
. Therefore, the class may violate the invariant that equal objects must have equal hashcodes.]]>hashCode
implementation to use is:- + This class defines a covariant version of equals()
. To correctly override theequals()
method injava.lang.Object
, the parameter ofequals()
@@ -1119,7 +1119,7 @@ the recommendedhashCode
implementation to use is:- + This code compares java.lang.String
objects for reference equality using the == or != operators. Unless both strings are either constants in a source file, or have been @@ -1130,7 +1130,7 @@ using theequals(Object)
method instead.]]>- + This code compares a java.lang.String
parameter for reference equality using the == or != operators. Requiring callers to pass only String constants or interned strings to a method is unnecessarily @@ -1140,7 +1140,7 @@ using theequals(Object)
method instead.]]>- + This class defines a covariant version of compareTo()
. To correctly override thecompareTo()
method in theComparable
interface, the parameter ofcompareTo()
@@ -1149,14 +1149,14 @@ using theequals(Object)
method instead.]]>- + This field is annotated with net.jcip.annotations.GuardedBy, but can be accessed in a way that seems to violate the annotation.]]> - + A web server generally only creates one instance of servlet or jsp class (i.e., treats the class as a Singleton), and will @@ -1167,7 +1167,7 @@ Thus, having a mutable instance field generally creates race conditions.]]> - + The fields of this class appear to be accessed inconsistently with respect to synchronization. This bug report indicates that the bug pattern detector judged that @@ -1195,7 +1195,7 @@ Thus, having a mutable instance field generally creates race conditions.]]> - + A call to notify()
ornotifyAll()
was made without any (apparent) accompanying modification to mutable object state. In general, calling a notify @@ -1211,7 +1211,7 @@ Thus, having a mutable instance field generally creates race conditions.]]>- + A public static method returns a reference to an array that is part of the static state of the class. Any code that calls this method can freely modify @@ -1222,7 +1222,7 @@ Thus, having a mutable instance field generally creates race conditions.]]> - + Returning a reference to a mutable object value stored in one of the object's fields exposes the internal representation of the object. If instances @@ -1235,7 +1235,7 @@ Thus, having a mutable instance field generally creates race conditions.]]> - + This code stores a reference to an externally mutable object into the internal representation of the object. If instances @@ -1248,7 +1248,7 @@ Thus, having a mutable instance field generally creates race conditions.]]> - + This code stores a reference to an externally mutable object into a static field. If unchecked changes to @@ -1259,7 +1259,7 @@ Thus, having a mutable instance field generally creates race conditions.]]> - + This method explicitly invokes run()
on an object. In general, classes implement theRunnable
interface because they are going to have theirrun()
method invoked in a new thread, @@ -1268,7 +1268,7 @@ Thus, having a mutable instance field generally creates race conditions.]]>- + This method spins in a loop which reads a field. The compiler may legally hoist the read out of the loop, turning the code into an infinite loop. The class should be changed so it uses proper @@ -1277,7 +1277,7 @@ Thus, having a mutable instance field generally creates race conditions.]]> - + This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). In addition, @@ -1300,7 +1300,7 @@ Language Specification for details - + This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). @@ -1318,7 +1318,7 @@ Language Specification for details - + Waiting on a monitor while two locks are held may cause deadlock. @@ -1331,7 +1331,7 @@ This not necessarily a bug, but is worth examining - + This method contains a call to java.lang.Object.wait()
which is not guarded by conditional control flow. The code should verify that condition it intends to wait for is not already satisfied @@ -1341,7 +1341,7 @@ This not necessarily a bug, but is worth examining- + This constructor reads a field which has not yet been assigned a value. This is often caused when the programmer mistakenly uses the field instead of one of the constructor's parameters.]]> @@ -1349,7 +1349,7 @@ This not necessarily a bug, but is worth examining- + This class contains similarly-named get and set methods where the set method is synchronized and the get method is not. This may result in incorrect behavior at runtime, as callers of the get @@ -1359,7 +1359,7 @@ This not necessarily a bug, but is worth examining - + A circularity was detected in the static initializers of the two classes referenced by the bug instance. Many kinds of unexpected behavior may arise from such circularity.]]> @@ -1367,7 +1367,7 @@ This not necessarily a bug, but is worth examining- + During the initialization of a class, the class makes an active use of a subclass. That subclass will not yet be initialized at the time of this use. For example, in the following code, foo
will be null. @@ -1385,7 +1385,7 @@ public class CircularClassInitialization {- + This class implements the java.util.Iterator
interface. However, itsnext()
method is not capable of throwingjava.util.NoSuchElementException
. Thenext()
@@ -1395,7 +1395,7 @@ public class CircularClassInitialization {- + The code synchronizes on interned String. private static String LOCK = "LOCK"; @@ -1412,7 +1412,7 @@ blocking and deadlock behavior. See- + The code synchronizes on a boxed primitive constant, such as an Boolean. private static Boolean inited = Boolean.FALSE; @@ -1432,7 +1432,7 @@ and possible deadlock]]>- + The code synchronizes on an apparently unshared boxed primitive, such as an Integer. @@ -1457,7 +1457,7 @@ throughout the JVM, leading to very confusing behavior and potential deadlock.- + The code synchronizes on a boxed primitive constant, such as an Integer. private static Integer count = 0; @@ -1475,7 +1475,7 @@ and possible deadlock]]>- + The code contains an empty synchronized block: synchronized() {} @@ -1489,7 +1489,7 @@ than less contrived solutions.- + The fields of this class appear to be accessed inconsistently with respect to synchronization. This bug report indicates that the bug pattern detector judged that @@ -1513,7 +1513,7 @@ than less contrived solutions. - + This method synchronizes on a field in what appears to be an attempt to guard against simultaneous updates to that field. But guarding a field gets a lock on the referenced object, not on the field. This may not @@ -1539,7 +1539,7 @@ private Long getNotificationSequenceNumber() { - + This method synchronizes on an object referenced from a mutable field. This is unlikely to have useful semantics, since different @@ -1549,7 +1549,7 @@ threads may be synchronizing on different objects.]]> - + A final static field that is defined in an interface references a mutable @@ -1565,7 +1565,7 @@ defined in an interface references a mutable - + A mutable static field could be changed by malicious code or by accident from another package. @@ -1576,7 +1576,7 @@ defined in an interface references a mutable - + A mutable static field could be changed by malicious code or by accident from another package. @@ -1586,7 +1586,7 @@ defined in an interface references a mutable - + A mutable static field could be changed by malicious code or by accident. The field could be made package protected to avoid @@ -1595,7 +1595,7 @@ defined in an interface references a mutable - + A final static field references a Hashtable and can be accessed by malicious code or by accident from another package. @@ -1604,7 +1604,7 @@ defined in an interface references a mutable - + A final static field references an array and can be accessed by malicious code or by accident from another package. @@ -1613,7 +1613,7 @@ defined in an interface references a mutable - + A mutable static field could be changed by malicious code or by accident from another package. @@ -1623,7 +1623,7 @@ defined in an interface references a mutable - + An inner class is invoking a method that could be resolved to either a inherited method or a method defined in an outer class. By the Java semantics, it will be resolved to invoke the inherited method, but this may not be want you intend. If you really intend to invoke the inherited method, @@ -1635,7 +1635,7 @@ that you want to invoke the inherited method, not the method in the outer class. - + This class has a simple name that is identical to that of its superclass, except that its superclass is in a different package (e.g., alpha.Foo
extendsbeta.Foo
). This can be exceptionally confusing, create lots of situations in which you have to look at import statements @@ -1646,7 +1646,7 @@ opportunities to accidently define methods that do not override methods in their