fb-contrib™: A FindBugs™ auxiliary detector plugin

fb-contrib can be used from the Findbugs™ Gui, Ant, or the eclipse plugin.

• To run fb-contrib from the gui, or ant, just place the fb-contrib jar in the plugins directory inside of the Findbugs™ directory.
• To run fb-contrib from eclipse, assuming that the main FindBugs plugin is installed, simply drop the fb-contrib.jar in the plugins directory of eclipse, and restart eclipse.

The latest version of fb-contrib is 7.4.3 available for download here.

This version requires FindBugs 3.0.1 or better

Please note that active development for this project is now done on github. If this site seems behind, please check there. I will try to keep this site up to date, but I'd appreciate a poke if you see something missing.

• [LUI] List Usage Issues
  Looks for odd usage patterns when using Lists
• [FII] Functional Interface Issues
  Looks for issues around use of @FunctionalInterface classes, especially in use with Streams
• [SUI] Set Usage Issues
  Looks for odd usage patterns when using Sets
• [CE] Class Envy
  Looks for methods that excessively use methods from another class. This probably means these methods should be defined in that other class.

• [UTWR] Use Try With Resources
  Looks for try/finally blocks that manage resources, without using try-with-resources.
• [RFI} Reflection Issues
  Looks for issues around reflection, especially in light of java 9 and 10.
• [AI] Annotation Issues
  Looks for issues around use of common annotations
• [MUI] Map Usage Issues
  Looks for odd usage patterns when using Maps

• [SSCU] Suspicious Shaded Class Use
  Looks for use of classes that have been shaded into 3rdparty jars, rather than using the real class, from the real jar.
• [USFW] Unsynchronized Singleton Field Writes
  Looks for field writes to objects that are non singletons, where the write is not synchronized
• [OI] Optional Issues
  Looks for various issues around use of java.util.Optional
• [UAC] Unnecessary Api Conversion
  Looks for code that appears to be using two forms of similar apis, an older one, and a new one. It finds code that creates newer api objects by first instantiating older api objects, and converting them into the new form. It is simpler just to create the new object directly.

• [DMC] Dubious Map Collection
  Looks for fields that are implementations of java.util.Map, but that are only ever iterated over. This probably means that this data structure should be a List of some class that holds two values, or at the least Pair. Map was probably choosen as it was the easiest thing to use, but obfuscates the reason for the data structure.
[BL] Burying Logic
Looks for relatively large if blocks of code, where you unconditionally return from them, and then follow that with an unconditional return of a small block. This places the bulk of the logic to the right indentation-wise, making it more difficult to read than needed. It would be better to invert the logic of the if block, and immediately return, allowing the bulk of the logic to be move to the left, for easier reading.
• [WI] Wiring Issues
  Looks for various issues around @Autowired/@Inject fields in DI classes
  • Injecting the same bean twice into the same class hierarchy, even with different field names
• [CCI] Concurrent Collection Issues
  Looks for various issues around using concurrent collections including
  • Using get/put with collection values, when you should use putIfAbsent

• [STB] Stacked Try Blocks
  Looks for two or more try catch blocks that are consecutive and catch the same kind of exception, and throw the same exception always. These blocks can be coalesced into one.
• [JPAI] JPA Issues
  Looks for various issues around the use of the Java Persistence API (JPA), including with use with spring-tx.
• [SEO] Suboptimal Expression Order
  Looks for conditional expressions where both simple local variable (in)equalities are used along with method calls, where the method calls are done first. By placing the simple local checks first, you eliminate potentially costly calls in some cases. This assumes that the methods called won't have side-effects that are desired. At present it only looks for simple sequences of 'and' based conditions.
• [IOI] IO Issues
  looks for various issues around input/output/streaming Library use.

• [OPM] Overly Permissive Method
  Looks for methods that are declared more permissively than the code is using. For instance, declaring a method public, when it could just be declared private.
• [STT] Stringified Types
  Looks for string fields that appear to be built with parsing or calling toString() on another object, or from objects that are fields.
• [IMC] Immature Class
  Looks for classes that are not fully implemented to be a well rounded class. While the class will likely work fine, it is more difficult to use or understand than necessary.
• [JXI] JAX-RS Issues
  Looks for problems with the use of the JAX-RS specification.

• [CSI] Charset Issues
  Looks for issues related to manually specified charsets by using string literals.
• [CBC] Contains based Conditional
  Looks for complex if expressions made up of multiple conditions joined by OR, whereit is much cleaner to build a static set of the possible values, and use the contains method on that set.
• [SLS] Suspicious Loop Search
  Looks for loops where an equality check is made and a variable is set because of it. It would seem once the item is found, the loop can be terminated, but is not.
• [CRF] Conflating Resources and Files
  Looks for code that uses the File api on URI/URLs where the reference is not a file based one. In the case of classpath URIs, this may work if the classpath is resolving to a folder, but will fall for jar files.

• [PSC] Presize Collections
  Looks for methods that create and populate collections, and while knowing the end size of those collections, does not pre allocate the collection to be big enough. This just causes unneeded reallocations putting strain on the garbage collector.
• [AIOB] Array Index Out of Bounds
  Looks for questionable load/stores to array elements.
  • Looks for accesses to array elements using literal values that are known to be outside the bounds of the array. This mistake will cause an ArrayIndexOutOfBoundsException to occur at runtime.
  • Looks for stores to array elements where the array itself appears to have not been allocated.
• [UJM] Unjitable Methods
  Looks for methods that are too big that the JIT will not compile them no matter how often they are run
• [HE] Hanging Executors
  Looks for executors that are never shutdown, which will not allow the application to terminate
  --contributed by Kevin Lubick - THANKS!
• [CTU] Conflicting Time Units
  Looks for methods that perform arithmetic operations on values representing time where the time unit is incompatible, i.e. adding a millisecond value to a nanosecond value.
• [HCP] HttpClient Problems
  The HttpRequests from the apache.httpComponents have some little-known quirks about them. This is a set of detectors that helps guard against resource starvation.
  --contributed by Kevin Lubick - THANKS!

• [CNC] Collection Naming Confusion
  Looks for fields and local variables that have Map, Set, List in their names but the variable is a collection of a different basic type.
• [PME] Poor Mans Enum
  Looks for simple fields that only store one of several constant values. This usually is an indication that this field should really be an enum type.
• [UP] Unused Parameter
  Looks for private or static methods that have parameters that aren't used. These parameters can be removed.
• [FCCD] Find Class Circular Dependencies
  Looks for class dependencies that where two or more classes rely on each other, either directly or indirectly. This often signifies an improper data model. Consider using interfaces to break this closed loop.
• [MUC] Modifying Unmodifiable Collection
  Looks for code that attempts to modify a collection that is or may be defined as immutable. for instance, being returned from Arrays.asList(). Doing so will cause exceptions at runtime.

• [LGO] Lingering Graphics Object
  Looks for creation of java.awt.Graphics object that do not have the .dispose() method called on them when finished. These objects will be cleaned up by the Garbage collector, bug given the likelyhood that large numbers of these objects can be created in a short period of time, it is better to dispose them as soon as possible.
• [CCNE] Compare Class Name Equals
  Looks for code that compares two classes by name, rather than by just comparing the classes with ==
  --contributed by Bhaskar Maddala - THANKS!
• [CSBTS] CommonsStringBuilderToString
  Looks for usage of ToStringBuilder from Apache commons, where the code invokes toString() on the constructed object without invoking append().
  Usage without invoking append is equivalent of using the Object.toString() method

  		new ToStringBuilder(this).toString();
  				

  --contributed by Bhaskar Maddala - THANKS!
• [CHTH] CommonsHashcodeBuilderToHashcode
  Looks for uses for Commons-lang HashCodeBuilder where the result of hashCode() is returned instead of calling the method toHashCode().
  --contributed by Bhaskar Maddala - THANKS!
• [BRPI] BackportReusePublicIdentifiers
  Looks for use of Backport Utils concurrent classes. Updated/Efficient version of these classes are available in versions of the JDK 5.0 and higher, and these classes should only be used if you are targeting JDK 1.4 and lower.
  --contributed by Bhaskar Maddala - THANKS!
• [CU] Clone Usability
  Looks for classes that implement clone() that do not specialize the return value, and do not swallow CloneNotSupportedException. Not doing so makes the clone method not as simple to use, and should be harmless to do.

• [SNG] Suspicious Null Guard
  Looks for code that checks to see if a field or local variable is not null before entering a code block either an if, or while statement, and reassigns that field or variable. It seems that perhaps the guard should check if the field or variable is null.
• [PUS] Possible Unsuspected Serialization
  Looks for serialization of non-static inner classes. As this serializes the enclosing class, it may unintentionally bring in more to the serialization than is wanted.
• [SEC] Side Effect Constructor
  Looks for constructors that operate through side effects, specifically constructors that aren't assigned to any variable or field. This makes the code more difficult to maintain as it has a tendency to increase cohesion between classes.
• [SGSU] Suspicious Getter Setter Use
  Looks for the setting of a java bean property with a value retrieved from the same bean's getter method for that property. This is usually a copy/paste typo.

• Eclipse plugin support by Andrei Loskutov - THANKS!

• [ROOM] Reflection on Object Methods
  Looks for method calls through reflection on methods found in java.lang.Object. As these methods are always available, there's no reason to do this.
• [IPU] Improper Properties Use
  Looks for java.util.Properties use where values other than String are placed in the properties object. As the Properties object was intended to be a String to String only collection, putting other types in the Properties object is incorrect, and takes advantage of a poor design decision by the original Properties class designers to derive from Hashtable, rather than using aggregation.
• [PCAIL] Possible Constant Allocation in Loop
  Looks for allocations of objects using the default constructor in a loop, where the object allocated is never assigned to any object that is used outside the loop. It is possible that this allocation can be done outside the loop to avoid excessive garbage.
• [WOC] Write Only Collection
  Looks for allocations and initializations of java collections, but that are never read from or accessed to gain information. This represents a collection of no use, and most probably can be removed. It is similar to a dead local store.
• [UVA] Use Var Args
  Looks for definitions of methods that have an array as the last parameter. Since this class is compiled with java 1.5 or better, it would be more flexible for clients of this method to define this parameter as a vararg parameter.

• [PDP] Poorly Defined Parameter
  Looks for non derivable methods that declare parameters and then cast those parameters to more specific types in the method. This is misleading and dangerous as you are not documenting through parameter types what is necessary for these parameters to function correctly.
• [OC] Overzealous Casting
  Looks for manual casts of objects that are more specific then needed as the value is assigned to a class or interface higher up in the inheritance chain. You only need to cast to that class or interface.
• [IKNC] Inconsistent Key Name Casing
  Looks for calls to HttpRequest.getParameter and HttpRequest.getAttribute with parameters of the same name with different cases like 'id' and 'Id'.
• [NSE] Non Symmetric Equals
  Looks for classes that break the fundamental rule of equivalence, which is symmetry. If a equals b, then b equals a. While it is usually wrong to allow equals to compare different types, at the very least you should make sure that each class knows about each other and is able to compare themselves with each other.
• [NFF] Non Functional Field
  Looks for fields in serializable classes that are defined as both final and transient. As a transient field is not initialized when streamed, and is not initialized in a constructor, it will remain null because it is defined final.
• [MDM] More Dumb Methods
  Looks for a variety of questionable method calls that will cause problems, are unsafe or use practices that might lead to bugs. --contributed by Chris Peterson - THANKS!

• Maven pom file contributed by Grzegorz Slowikowski - THANKS!

• [TBP] Tristate Boolean Pattern
  Looks for methods that are defined to return Boolean, but return null. This thus allows three return values, Boolean.FALSE, Boolean.TRUE and null. If three values are intended, it would be more clear to just create an enumeration with three values and return that type.
• [SUA] Suspicious Uninitialized Array
  Looks for creation of arrays, that are not populated before being returned for a method. While it is possible that the method that called this method will do the work of populated the array, it seems odd that this would be the case.
• [ITU] Inappropriate ToString Use
  Looks for methods that rely on the format of the string fetched from another object's toString method, when that method appears not to be owned by the author of the calling method. As the implementation of toString() is often considered a private implementation detail of a class, and not something that should be relied on, depending on its format is dangerous.
• [BED] Bogus Exception Declaration
  Looks for constructors, private methods or static methods that declare that they throw specific checked exceptions, but that do not. This just causes callers of these methods to do extra work to handle an exception that will never be thrown.
• [DTEP] Deprecated Typesafe Enum Pattern
  Looks for classes that appear to implement the old style type safe enum pattern that was used before java added Enum support to the language. Since this class is compiled with java 1.5 or later, it would be simpler to just use java enums.
• [UNNC] Unnecessary New Null Check
  Looks for construction of new objects, and then the immediate testing whether the object is null or not. As the new operator will always succeed, or through an exception, this test is unnecessary and represents a misunderstanding as to how the jvm works.

• [DSOC] Dubious Set of Collections
  Looks for sets or keySets of maps that contain other collections. As typically collections calculate their hashCode, equals and compareTo methods by iterating the collection and evaluating the same function on each item in the collection, this can be costly from a performance point of view. In addition, using a set, or keySet of a map, infers that you will be looking for items based on the value of a collection, which seems dubious at best. Finally, as collections are often modified, This may cause problems if the collection is modified, thus changing hashCodes, etc, while the collection is in the set. If you wish to keep a collection of collections, the outer collection should probably be a list to avoid these problems
• [IICU] Incorrect Internal Class Use
  Looks for classes that use objects from internal sun, xerces or xalan packages. As these are internal to the respective products and subject to change or removal, these should not be used.
• [LO] Logger Oddities
  Looks for uses of log4j or slf4j where the class specified when creating the logger is not the same as the class in which this logger is used. Also looks for using concatenation with slf4j logging rather than using the parameterized interface.
• [SCSS] Suspicious Clustered Session Support
  Looks for methods that access objects in http sessions, that are complex objects, modifies those objects, but does not call setAttribute to signify a change so that cluster replication can happens correctly.

• [CFS] Confusing Function Semantics
  Looks for methods that return a parameter after making what looks like modifications to that parameter. This leads to confusion for the user of this method as it isn't obvious that the 'original' object is modified. If the point of this method is to modify the parameter, it is probably better just to have the method be a void method, to avoid confusion.
• [SCA] Suspicious Clone Algorithm
  Looks for implementation of clone where an assignment is made to a field of the source object. It is likely that that store should have occurred on the cloned object, as the clone operation is almost always considered read only.
• [UTAO] Unit Test Assertion Oddities
  Looks for junit or testng test case methods that use assertions with odd parameters. Things such as, passing a constant as the second (actual) parameter, not using the three parameter version of asserts for doubles, or passing true or false as the first parameter instead of using assertTrue, or assertFalse.
• [WEM] Weak Exception Messaging
  Looks for exceptions that are thrown with static strings as messages. Using static strings doesn't differentiate one use of this method versus another, and so it may be difficult to determine how this exception occurred without showing context.

• [SJVU] Suspicious JDK Version Use
  Looks for calls to classes and methods that do not exist in the JDK for which this class is compiled. This can happen if you specify the -source and -target options of the javac compiler, and specify a target that is less than the jdk version of the javac compiler.
• [UAA] Use Add All
  Looks for loops that transfers the contents of one collection to another. These collection sources might be local variables or member fields, including sets, maps key/values, lists, or arrays. It is simpler to just use the addAll method of the collection class. In the case where the source is an array, you can use Arrays.asList(array), and use that as the source to addAll.
• [MRC] Method returns Constant
  Looks for private methods that can only return one constant value. Either the class should not return a value, or perhaps a branch was missed.
• [NCS] Needless Custom Serialization
  Looks for classes that implement Serializable and implements readObject and writeObject by just calling the readDefaultObject or writeDefaultObject of the stream parameter. As this is the standard behavior, implementing these methods is not needed.
• [EXS] Exception Softening
  Looks for methods that catch checked exceptions, and throw unchecked exceptions in their place. There are several levels of concern. Least important are methods constrained by interface or super class contracts not to throw checked exceptions but appear owned by the same author. Next are methods constrained by interface or super class contracts and throw other types of checked exceptions. Lastly are method not constrained by any interface or superclass contract.
  

• [SCRV] Suspicious Comparator Return Values
  Looks for classes that implement Comparator or Comparable, and whose compare or compareTo methods return constant values only, but that don't represent the three possible choices (a negative number, 0, and a positive number).
• [SPP] Sillyness Pot Pourri
  Looks for various small problems that don't fall into any particular category.
• [SCII] Spoiled Child Interface Implementor
  Looks for classes that implement interfaces by relying on methods being implemented in superclasses, even though the superclass knows nothing about the interface being implemented by the child.
• [DWI] Deleting While Iterating
  Looks for deletion of items from a collection using the remove method of the collection at the same time that the collection is being iterated on. If this occurs the iterator will become invalid and throw a ConcurrentModificationException. Instead, the remove should be called on the iterator itself.
• [USS] Use String Split
  Looks for code that builds an array by using a StringTokenizer to break up a string and place individual elements into an array. It is simpler to use String.split instead.

• [LEST] Lost Exception Stack Trace
  Looks for methods that catch exceptions, and rethrow another exception without encapsulating the original exception within it. Doing this loses the stack history, and where the original problem occurred. This makes finding and fixing errors difficult.
• [UCPM] Use Character Parameterized Method
  Looks for methods that pass single character string constants as parameters to methods that alternatively have an overridden method that accepts a character instead. It is easier for the method to handle a single character than a String.
• [TR] Tail Recursion
  Looks for methods that make a recursive call to itself as the last statement in the method. This tail recursion could be converted into a simple loop which would improve the performance and stack requirements.
• [URV] Unrelated Return Values
  Looks for methods that return Object, and who's code body returns two or more different types of objects that are unrelated (other than by Object).
• [PIS] Possible Incomplete Serialization
  Looks for classes that don't handle serialization of parent class member fields when the class in question is serializable but is derived from non serializable classes.
  

• [NMCS] Needless Member Collection Synchronization
  Looks for private collection members, either static or instance, that are only initialized in the clinit or init, but are synchronized. This is not necessary as the constructor or static initializer are guaranteed to be thread safe.
• [ITC] Inheritance Type Checking
  Looks for if/else blocks where a series of them use instanceof on the same variable to determine what to do. If these classes are related by inheritance, this often is better handled through calling a single overridden method.
• [PRMC] Possibly Redundant Method Calls
  Looks for calls of the same method on the same object when that object hasn't changed. This often is redundant, and the second call can be removed, or combined.
• [UTA] Use toArray
  Looks for code that builds an array of values from a collection, by manually looping over the elements of the collection, and adding them to the array. It is simpler and cleaner to use mycollection.toArray(new type[mycollection.size()].

• [FCBL] Field could be Local
  Looks for classes that declare fields that are used in a locals-only fashion, specifically private fields that are accessed first in each method with a store vs. a load. These fields can be declared as one or more locals.
• [NOS] Non Owned Synchronization
  Looks for methods that synchronize on variables that are not owned by the current class. Doing this causes confusion when two classes use the same variable for their own synchronization purposes. For cleanest separation of interests, only synchronize on private fields of the class. Note that 'this' is not owned by the current class and synchronization on 'this' should be avoided as well.
• [S508C] Section 508 Compliance
  Looks for classes and methods that do not support coding styles that allow Accessibility software to make full use of the gui for people with visual impediments. Commonly known as 'Section 508 Compliance' this detector finds a varied list of issues that hamper screen readers, and make color/size adjustments difficult.
• [UEC] Use Enum Collections
  Looks for uses of sets or maps where the key is an enum. In these cases, it is more efficient to use EnumSet or EnumMap. It is a jdk1.5 only detector.

• [DDC] Double Date Compare
  Looks for methods that compare two dates using .equals and after or before. This combination of two comparisons can be accomplished with just one comparison.
• [JVR] JDBC Vendor Reliance
  Looks for uses of jdbc vendor specific classes and methods making the database access code non portable.
• [PMB] Possible Memory Bloat
  Looks for classes that maintain collections or StringBuffer/StringBuilders in static member variables, and that do not appear to provide a way to clear or remove items from these members. Such class fields are likely causes of memory bloat.
• [LSYC] Local Synchronized Collection
  Looks for allocations of synchronized collections that are stored in local variables, and never stored in fields or returned from methods. As local variables are by definition thread safe, using synchronized collections in this context makes no sense.

• [CLI] Constant List Index
  Looks for methods that access an array or list using a constant integer index. Often, this is a typo where a loop variable is intended to be used. If however, specific list indices mean different specific things, then perhaps replacing the list with a first-class object with meaningful accessors would make the code less brittle.
• [SCR] Sloppy Class Reflection
  Looks for methods that use Class.forName("XXX") to load a class object for a class that is already referenced by this class. It is simpler to just use XXX.class, and doing so protects the integrity of this code from such transformations as obfuscation. Use of Class.forName should only be used when the class in question isn't already statically bound to this context.
• [AWCBR] Array Wrapped Call By Reference
  Looks for methods that use an array of length one to pass a variable to achieve call by pointer ala C++. It is better to define a proper return class type that holds all the relevant information retrieved from the called method.
• [SG] Sluggish Gui
  Looks for methods that implement awt or swing listeners and perform time consuming operations. Doing these operations in the gui thread will cause the interface to appear sluggish and non-responsive to the user. It is better to use a separate thread to do the time consuming work so that the user has a better experience.
• [NIR] Needless Instance Retrieval
  Looks for methods that call a method to retrieve a reference to an object only to then load a static field of that object's class. It is simpler and more performant to just directly load the field from the class itself.

• [ABC] Array Based Collections
  Looks for methods that use arrays for items in the keyset of a map, or as an element of a set, or in a list when using the contains method. Since arrays do not, and cannot define an equals method, reference equality is used for these collections, which is probably not desired. If it is, consider using the IdentityHashMap class when using Maps in this case, to better document your intentions.
• [ODN] Orphaned DOM Nodes
  Looks for methods that create DOM nodes but do not append them to any Document.
• [A0M] Abstract Overridden Method
  Looks for abstract methods that override a concrete method in a super class. Doing this casts away the implementation of the super class, and breaks the implied contract as set forth by the parent class.
• [CBX] Custom Built XML
  Looks for methods that build xml based strings by concatenation strings and custom values together. Doing so makes brittle code, that is difficult to modify, validate and understand. It is cleaner to create external xml files that are transformed at runtime, using parameters set through Transformer.setParameter.

• [STS] Spurious Thread States
  Finds methods that call wait, notify or notifyAll on an instance of a java.lang.Thread. Since the internal workings of the thread is to synchronize on the thread itself, introducing client calls will confuse the thread state of the object in question, and will cause spurious thread state changes, either waking threads up when not intended, or removing the thread from the runnable state.
• [NAB] Needless Autoboxing
  Finds methods that pass an instance of a primitive wrapper class, to a constructor of the same class. Since wrapper classes are immutable, you can just use the original instance, instead of creating a new one. This bug is a misuse of autoboxing.
• [USBR] UnnecessaryStoreBeforeReturn
  Finds methods that store the return result in a local variable, and then immediately returns that local variable.
• [COM] CopiedOverriddenMethod
  Finds methods that are implemented with an exact copy of their super class method's implementation. In most cases, this means that this method can just be removed.

• [SMII] Static Method Instance Invocation
  Finds methods that make static method calls using an instance reference. For documentation purposes, it is better to call the method using the class name. This may represent a change in definition that should be noticed.
• [AFBR] Abnormal Finally Block Return
  Finds methods that return or throw an exception from a finally block. Since a finally block is executed after any return or throw statements that are present in the try or catch block, these exit values are swallowed by the finally block's actions.
• [NCMU] Non Collections Method Use
  Finds calls to collections objects using methods that are not defined in the Collections interfaces, but that have equivalent methods defined in such. By using the new methods, it allows for the replacement of concrete classes with interfaces, and simplifies changing collection types if desired.
• [CAO] Confusing Autoboxed Overloading
  Finds classes that define overloaded methods where the only difference is a parameter being of type java.lang.Character, and int, long, float or double. Due to autoboxing, one might conclude that a parameter of 'a' would autobox to Character, but would instead be cast to a double.

• [FP] Final Parameters
  Finds parameters that could be marked as final, but aren't. Doing so helps document the method, keeps unwanted changes to creep in, and may help the jvm jit compiler to optimize better.
• [ACEM] Abstract Class Empty Methods
  Finds empty methods, or methods that just throw an exception in abstract classes. In these cases, it probably is more correct to just define the method to be abstract as well, so that proper subclass implementation is enforced.
• [MAC] Manual Array Copy
  Finds methods that copy elements from one array to another manually using a loop. It is better performing to use System.arraycopy, as this method is native.
• [FPL] Floating Point Loops
  Finds methods that use floating point variables as the index to loops. Since floating point math is inprecise, errors will accumulate each time through the loop, making the logic suspect. It is better to use an integer index, and calculate the desired floating point value from this integer.

• [PL] Parallel Lists
  Finds classes that maintain two or more lists or arrays that appear to share a one-to-one relationship through a common index. It is usually better to create a separate class that holds all corresponding attributes, and add instances of this class to just one list or array.
• [DLC] Dubious List Collection
  Finds fields that are implementations of java.util.List, but that are used in a set-like fashion. Since lookup type operations are performed using a linear search for Lists, the performance for large Lists will be poor. Consideration should be made as to whether these fields should be sets.
• [PCOA] Partially Constructed Object Access
  Finds constructors that call non-final methods in non-final classes. If this class is derived from, and the method is overridden, then that method will be executing on an object that hasn't been constructed in regards to the subclass implementation. These methods should probably be defined as final.
• [LSC] Literal String Comparison
  Finds methods that call the equals or compareTo methods on a String variable passing in a String literal. A NullPointerException may occur if the string variable is null. If instead the method was called on the string literal, and the variable was passed as an argument, this exception could never happen

• [OCP] Overly Concrete Parameters
  Finds parameters to methods that are defined as concrete classes, when they're usage pattern can be defined by an implemented interface. By switching to the interface, you can reduce coupling, which helps making the code more testable and changeable.
• [LII] List Indexed Iterating
  Looks for uses of using loop indexed variables to 'iterate' over a List by calling get(i) each time thru the loop. Depending on the List implementation, using Iterators can be significantly faster. Using Iterators also makes it easier to substitute other collection types.
• [UCC] Unrelated Collection Contents
  Looks for collections that hold objects that are unrelated by class or interface inheritance, other than java.lang.Object. Doing so, leads to brittle code, either by 'encoding' type knowledge in the position of an element, or using instanceof tests. It is usually better to create a separate class, add the individual types as members to it, and add an instance of this class to the collection.
• [DRE] Declared Runtime Exception
  Finds methods that declare RuntimeExceptions in their throws clause. While not illegal, this may indicate a misunderstanding as to how unchecked exceptions are handled. If is felt that a RuntimeException is so prevalent that it should be declared, it is probably a better idea to prevent the occurance in code.

• [ISB] Inefficient String Buffering
  Finds Concatenation inside of a StringBuffer.append call, which creates temporary StringBuffers.
• [SCI] Synchronized Collection Iterators
  Finds use of iterators on collections built from Collection.synchronizedXXX() calls. As iterators are by default not multithread safe, there use with a synchronized collections seems dubious.
• [CC] Cyclomatic Complexity
  Finds methods that are overly complex based on the McCabe algorithm for counting number of unique branches in the method