This method passes an array as the key to a Map, element in a Set, or item in a List when the contains method is used on the List. Since arrays do not and cannot override the equals method, collection inclusion is based on the reference's address, which is probably not desired. In the case that this is a TreeMap or TreeSet, consider passing a Comparator to the map's constructor.
This method is empty or merely throws an exception. Since the class it is defined in is abstract, it may be more correct to define this method as abstract instead, so that proper subclass behavior is enforced.
This method returns or throws exceptions from a finally block. This will mask real program logic in the try block, and short-circuit normal method termination.
This method accesses an array element using a literal index that is known to be outside the size of the specified array. This will cause an ArrayIndexOutOfBoundsException at runtime.
This method attempts to store an array element into an array that appears not to have been allocated.
This method can return null, but is not annotated with an @Nullable annotation. Without this annotation, various IDEs, and static analysis tools may not be able to fully discover possible NullPointerExceptions in your code. By adding these annotations, you will discover problems around null-ness, more easily.
Unfortunately there isn't just one @Nullable annotation, but this detector will recognize:
You can supply a comma separated list of classes that are custom Nullable Annotations if you desire, by using the system property -Dfb-contrib.ai.annotations="com.acme.Foo,com.acme.Boo" when run.
This method accesses an array element using a literal index that is known to be outside the size of the specified array. This will cause an ArrayIndexOutOfBoundsException at runtime.
This method attempts to store an array element into an array that appears not to have been allocated.
This abstract method is derived from a concrete method implementation. It is highly suspect that the superclass method's implementation would be cast away.
This method uses a one-element array to wrap an object that is to be passed to a method as an argument to simulate 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.
THIS DETECTOR IS HIGHLY EXPERIMENTAL AND IS LIKELY TO CREATE A LOT OF FUD
This method assigns a value to a variable in an outer scope compared to where the variable is actually used. Assuming this evaluation does not have side effects, the assignment can be moved into the inner scope (if block) so that its execution time isn't taken up if the if guard is false. Care should be taken, however, that the right hand side of the assignment does not contain side effects that are required to happen, and that changes are not made further down that will affect the execution of the assignment when done later on.
This method declares that it throws an exception that is the child of another exception that is also declared to be thrown. Given that the parent exception is declared, there is no need for the child exception to also be declared; it just adds confusion.
This method declares that it throws a checked exception that it does not throw. As this method is either a constructor, static method or private method, there is no reason for this method to declare the exception in its throws clause, and just causes calling methods to unnecessarily handle an exception that will never be thrown. The exception in question should be removed from the throws clause.
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.
This class uses either Backport Utils concurrent classes from Emory, or Time classes from ThreeTen Backport. Updated/efficient versions of these classes are available in the version of the JDK that this code is compiled against - JDK 1.5 for the concurrent classes, and JDK 1.8 for the time classes - and these classes should only be used if you are targeting a JDK lower than this.
This method implements a synchronized block, but the code found at the beginning of this block only accesses local variables, and not member variables or this. For better performance, move the code that accesses local variables only above the synchronized block, and leave the synchronized block only for field accesses, or access to this.
This method passes an array of primitive values to the Arrays.asList call. As primitive values in arrays aren't automatically promoted to boxed primitives in arrays, the asList call cannot convert this array to a list of boxed primitives. It therefore just creates an array with one item in it, the array itself. This is rarely what is desired.
This class defines two methods that differ only by a parameter being defined as Character vs. int, long, float or double. As autoboxing is present, it may be assumed that a parameter of 'a' would map to the Character version, but it does not.
This method uses an overly complex if expression made up of multiple conditions joined by OR, where the same local variable is compared to a static value. When the number of conditions grows, it is much cleaner to build a static set of the possible values, and use the contains method on that set. This will shorten the code, and make it more self documenting.
This method generates an XML based string by concatenating together various XML fragments, and variable values. Doing so makes the code difficult to read, modify and validate. It is much cleaner to build XML structures in external files that are read in and transformed into the final product, through modification by Transformer.setParameter.
In a JVM, two classes are the same class (and consequently the same type) if they are loaded by the same class loader, and they have the same fully qualified name [JVMSpec 1999]. Comparing class name ignores the class loader.
This method retrieves the value of a key from a ConcurrentHashMap, where the value is itself a collection. It checks this value for null, and if it is so, creates a new collection and places it in the map. This may cause thread race conditions where two threads overwrite each other's values. You should be using ConcurrentHashMap.putIfAbsent(K, V) instead.
This method has a high cyclomatic complexity figure, which represents the number of branch points. It is likely difficult to test, and is brittle to change. Consider refactoring this method into several to reduce the risk.
This method retrieves the value of a key from a ConcurrentHashMap, where the value is itself a collection. It checks this value for null, and if it is so, creates a new collection and places it in the map. This may cause thread race conditions where two threads overwrite each other's values. You should be using ConcurrentHashMap.putIfAbsent(K, V) instead.
In a JVM, two classes are the same class (and consequently the same type) if they are loaded by the same class loader, and they have the same fully qualified name [JVMSpec 1999]. Comparing class name ignores the class loader.
This method makes extensive use of methods from another class over methods of its own class. Typically this means that the functionality that is accomplished by this method most likely belongs with the class that is being used so liberally. Consider refactoring this method to be contained in that class, and to accept all the parameters needed in the method signature.
This method returns the result of equals on the EqualsBuilder type instead of calling the method isEqual().
This method returns the result of equals on the EqualsBuilder type instead of calling the method isEqual().
This method appears to modify a parameter, and then return this parameter as the method's return value. This will be confusing to callers of this method, as it won't be apparent that the 'original' passed-in parameter will be changed as well. If the purpose of this method is to change the parameter, it would be more clear to change the method to have a void return value. If a return type is required due to interface or superclass contract, perhaps a clone of the parameter should be made.
This method returns the result of hashCode on the HashCodeBuilder type instead of calling the method toHashCode().
This method accesses 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.
This class defines a field or local collection variable with a name that contains a different type of collection in its name. An example would be a Set
This method is implemented using an exact copy of its superclass method's implementation, which usually means that this method can just be removed.
This method is implemented to just delegate its implementation by calling the superclass method with the same signature. This method can just be removed.
This method fetches a resource from a URL, and uses the File API to manipulate it. If this resource is a classpath resource, it will work if the resource is a file in a directory. If, however, the file is inside a JAR file this will fail. To avoid this confusing inconsistency, use the URL.openStream API instead to access the data of the classpath resource.
This method returns the result of toString on a ToStringBuilder without an intermediate invocation of append().
This method uses a string literal to specify a Charset encoding. However, the method invoked has an alternative signature that takes a Charset object. You should use this signature, as this class is compiled with JDK 7 (or better), and the Charset in question is available as a constant from the java.nio.charset.StandardCharsets class.
Instead of specifying "UTF-8", use StandardCharsets.UTF_8, for instance. An added benefit of this is that you will not need to catch UnsupportedEncodingException.
This method uses a hand-typed String literal to specify a Charset encoding. As this class is compiled with JDK 7 (or better), and the charset in question is available as a constant from the java.nio.charset.StandardCharsets class, it is better to use the .name() method of the appropriate StandardCharsets constant.
The method in question doesn't directly support a Charset as a parameter, only a String. Still, instead of specifying something like "UTF-8" (and potentially mistyping it), use StandardCharsets.UTF_8.name().
This method specifies a Charset encoding with a String literal that is not recognized by the current JDK. It's possible that this application will only be deployed on a JVM that does recognize this encoding, but it seems dubious that this is the case.
The standard JDK encodings (for Java 8) are "UTF-8", "US-ASCII", "ISO-8859-1", "UTF-16BE", "UTF-16LE", "UTF-16". These are all case-sensitive.
This method takes two values that appear to be representing time, and performs arithmetic operations on these two values directly, even though it appears that the two values are representing different time units, such as adding a millisecond value to a nanosecond value. You should convert the two values to the same time unit before performing this calculation in order for it to be meaningful.
This class implements the Cloneable interface but defines its clone method to return an Object. Since most likely users of this method will need to cast it to the real type, this will be more painful than necessary. Just declare the return value to be the type of this class.
This class implements the Cloneable interface but defines its clone method to return a type that is different than the class itself, or any interfaces that the class implements.
This class implements the Cloneable interface but defines its clone method to still throw a CloneNotSupportedException. Since you are implementing clone() it would make sense that the method in question will not throw that exception, so annotating your method with it just makes clients' use of your class more painful as they have to handle an exception that will never happen. Just remove the throws clause from your method.
This method contains a contravariant array assignment. Since arrays are mutable data structures, their use must be restricted to covariant or invariant usage.
class A {} class B extends A {} B[] b = new B[2]; A[] a = b; This method contains a contravariant array element assignment. Since arrays are mutable data structures, their use must be restricted to covariant or invariant usage.
class A {} class B extends A {} B[] b = new B[2]; A[] a = b; a[0] = new A(); // results in ArrayStoreException (Runtime) This method compares dates with two comparisons, rather than using the reverse comparison. So this pattern
if ((date1.equals( date2 )) || (date1.after( date2 ))) if (date1.compareTo( date2 ) >= 0) if ((date1.equals( date2 )) || (date1.before( date2 ))) if (date1.compareTo( date2 ) <= 0) if ((date1.before( date2 )) || (date1.after( date2 ))) if (!date1.equals( date2 )) This class defines a field based on java.util.List, but uses it to some extent like a Set. Since lookup type operations are performed using a linear search for Lists, the performance for large Lists will be poor. If the list is known to only contain a small number of items (3, 4, etc), then it doesn't matter. Otherwise, consider changing this field's implementation to a set-based one. If order of iteration is important to maintain insert order, perhaps consider a LinkedHashSet.
This method instantiates a map-type field in a static initializer or constructor, but then only uses it through iteration. This means that this data structure should really just be a List<SomeObject>, where the class held by the list contains the two fields held by the key and value of the Map. It was likely done this way to avoid having to create a class, but this just obfuscates the purpose of the field.
This method declares a RuntimeException derived class in its throws clause. This may indicate a misunderstanding as to how unchecked exceptions are handled. If it is felt that a RuntimeException is so prevalent that it should be declared, it is probably a better idea to prevent the occurrence in code.
This method creates a set that contains other collections, or a Map whose keySet is another collection. As collections tend to calculate hashCode, equals, and compareTo by iterating the contents of the collection, this can perform poorly.
In addition, when a set is used, you typically are using it to do 'contains', or 'find' type functionality, which seems dubious when done on a collection.
Finally, as a collection is often modified, problems will occur if the collection is contained in a set, because the hashCode, equals or compareTo values will change while the collection is in the set.
If you wish to maintain a collection of collections, it is probably better to use a List as the outer collection.
This class appears to implement the old-style typesafe enum pattern that was used in place of real enums. Since this class is compiled with Java 1.5 or better, it would be simpler and more easy to understand if it was just switched over to an enum.
This method removes items from a collection using the remove method of the collection, while at the same time iterating across the collection. Doing this will invalidate the iterator, and further use of it will cause ConcurrentModificationException to be thrown. To avoid this, the remove method of the iterator should be used.
This method modifies the contents of a collection using the collection API methods, while at the same time iterating across the collection. Doing this will invalidate the iterator, and further use of it will cause ConcurrentModificationException to be thrown.
This method's exception signature is constrained by an interface or superclass not to throw any checked exceptions. Therefore a caught checked exception was converted to an unchecked exception and thrown. However, it appears that the class in question is owned by the same author as the constraining interface or superclass. Consider changing the signature of this method to include the checked exception.
This method's exception signature is constrained by an interface of superclass not to throw a checked exception that was caught. Therefore this exception was converted to an unchecked exception and thrown. It would probably be better to throw the closest checked exception allowed, and to annotate the new exception with the original exception using the initial cause field.
This method catches an exception and returns a boolean that represents whether an exception occurred or not. This throws away the value of exception handling and lets code ignore the resultant 'error code' return value. You should just throw the exception to the caller instead.
This method is not constrained by an interface or superclass, but converts a caught checked exception to an unchecked exception and throws it. It would be more appropriate just to throw the checked exception, adding the exception to the throws clause of the method.
This class defines fields that are used in a local only fashion, specifically private fields or protected fields in final classes that are accessed first in each method with a store vs. a load. This field could be replaced by one or more local variables.
This class has a circular dependency with other classes. This makes building these classes difficult, as each is dependent on the other to build correctly. Consider using interfaces to break the hard dependency. The dependency chain can be seen in the GUI version of FindBugs.
This method builds a collection using lambda expressions with a collect terminal operation. It then immediately calls the contains() method on it, to see if an item is present. This is sub optimal as the lambda still needs to build the entire collection, iterating the entire source list. It is better to use anyMatch() to short circuit the building of the collection.
Instead of baubles.stream().map(Bauble::getName).collect(Collectors.toSet()).contains(name)
baubles.stream().anyMatch(b -> name.equals(b.getName()))
This method builds a collection using lambda expressions with a collect terminal operation. It then immediately calls the size() method on it, to get a count of items. This is sub optimal as the lambda still needs to build the entire collection, iterating the entire source list. It is better to use count() predicate to short circuit the building of the collection. If you were using a Set, then also add the distinct() predicate.
Instead of baubles.stream().filter(b -> b.getName("orb")).collect(Collectors.toList()).size()) baubles.stream().filter(b -> b.getName("orb")).count() or for sets you can use baubles.stream().filter(b -> b.getName("orb")).distinct().count()
This method streams data into a List just to call get(0) to get the first item. You can just use findFirst() to short circuit the processing of the stream.
Instead of baubles.stream().collect(Collectors.toList()).get(0)
baubles.stream().findFirst().get())
This method defines an anonymous lambda function to be called to fetch a single value from the passed in value. While this will work, it is needlessly complex as this function merely calls a single getter method on the object, and thus the code can be simplied by just passing in a method reference instead.
Instead of baubles.stream().map(b -> b.getName()).collect(Collectors.toSet())
baubles.stream().map(Bauble::getName).collect(Collectors.toSet())
This method declares a no-op (identity) lambda method rather than just specifying Function.identity()
This method streams data using more than one filter back to back. These can just be combined into one filter
This method looks for one item in a stream using filter().findFirst.isPresent() when .anyMatch() will do the same thing more succintly
This method does not write to a parameter. To help document this, and to perhaps help the JVM optimize the invocation of this method, you should consider defining these parameters as final.
Performance gains are debatable as "the final keyword does not appear in the class file for local variables and parameters, thus it cannot impact the runtime performance. Its only use is to clarify the coder's intent that the variable not be changed (which many consider dubious reason for its usage), and dealing with anonymous inner classes." - http://stackoverflow.com/a/266981/1447621
This method uses floating point variables to index a loop. Since floating point math is imprecise, rounding errors will accumulate over time each time the loop is executed. It is usually better to use integer indexing, and calculate the new value of the floating point number at the top of the loop body.
Example:
for (float f = 1.0f; f <= 10.0f; f += 0.1f) { System.out.println(f); } This method uses floating point variables to index a loop. Since floating point math is imprecise, rounding errors will accumulate over time each time the loop is executed. It is usually better to use integer indexing, and calculate the new value of the floating point number at the top of the loop body.
Example:
for (float f = 1.0f; f <= 10.0f; f += 0.1f) { System.out.println(f); } FindBugs has detected an org.apache.http.HttpRequest (e.g. HttpGet, HttpPost, etc) that didn't release its associated resources. Code like the following:
code> private HttpGet httpGet; public String requestInfo(URI u) { this.httpGet = new HttpGet(u); try(CloseableHttpResponse response = client.execute(httpGet);) { return getResponseAsString(response); } catch (IOException e) { e.printStackTrace(); } return null; } will freeze after a few requests, usually with no indication as to why. The reason this code freezes is because org.apache.http.HttpRequests need to explicitly release their connection with a call to either reset() or releaseConnection(). The above example can be easily fixed:
private HttpGet httpGet; ... public String requestInfo(URI u) { this.httpGet = new HttpGet(u); try(CloseableHttpResponse response = client.execute(httpGet);) { return getResponseAsString(response); } catch (IOException e) { e.printStackTrace(); } finally { this.httpGet.reset(); } return null; }
FindBugs has detected an org.apache.http.HttpRequest (e.g. HttpGet, HttpPost, etc) that didn't release its associated resources. Code like the following:
public String requestInfo(URI u) { HttpGet httpGet = new HttpGet(u); try(CloseableHttpResponse response = client.execute(httpGet);) { return getResponseAsString(response); } catch (IOException e) { e.printStackTrace(); } return null; } The reason this code freezes is because org.apache.http.HttpRequests need to explicitly release their connection with a call to either reset() or releaseConnection(), even if the request is a local. The garbage collector will not release these resources, leading to the frustrating freezing scenario described above.
The above example can be easily fixed:
public String requestInfo(URI u) { HttpGet httpGet = new HttpGet(u); try(CloseableHttpResponse response = client.execute(httpGet);) { return getResponseAsString(response); } catch (IOException e) { e.printStackTrace(); } finally { httpGet.reset(); } return null; } Most ExecutorService objects must be explicitly shut down, otherwise their internal threads can prevent the JVM from ever shutting down, even when everything else has stopped.
FindBugs has detected that something like the following is happening:
ExecutorService executor = ... //e.g. Executors.newCachedThreadPool(); ... public void reset() { this.executor = Executors.newCachedThreadPool(); this.executor.execute(new SampleExecutable()); }
ExecutorServices, this isn't enough to terminate the internal threads in the thread pool, and the ExecutorService isn't guaranteed to shut down, causing the JVM to never stop. shutdown() like this: ExecutorService executor = ... //e.g. Executors.newCachedThreadPool(); ... public void reset() { this.executor.shutDown(); //Fix this.executor = Executors.newCachedThreadPool(); this.executor.execute(new SampleExecutable()); } Even though there are some exceptions to this, particularly when a custom ThreadFactory is provided, or for ThreadPoolExecutors with allowsCoreThreadTimeOut() set to true, it is good practice to explicitly shut down the ExecutorService at the end of execution, or when it is being replaced.
Note: ExecutorServices are generally created once in a program's life cycle. If you find yourself replacing the ExecutorService, perhaps you may consider restructuring your code to use calls like awaitTermination() or Futures/Callables to avoid recreating the ExecutorService.
Most ExecutorService objects must be explicitly shut down, otherwise their internal threads can prolong the running of the JVM, even when everything else has stopped.
FindBugs has detected that there are no calls to either the shutdown() or shutdownNow() method, and thus, the ExecutorService is not guaranteed to ever terminate. This is especially problematic for Executors.newFixedThreadPool() and most of the other convenience methods in the Executors class.
Even though there are some exceptions to this, particularly when a custom ThreadFactory is provided, or for ThreadPoolExecutors with allowsCoreThreadTimeOut() set to true, it is good practice to explicitly shutdown the ExecutorService when its utility is done.
ExecutorServices are typically instantiated as fields so that many tasks can be executed on a controlled number of Threads across many method calls. Therefore, it is unusual for ExecutorServices to be a local variable, where tasks will be added only one time, in the enclosing method.
Furthermore, when a local ExecutorService reaches the end of scope and goes up for garbage collection, the internal Threads are not necessarily terminated and can prevent the JVM from ever shutting down.
Consider making this local variable a field and creating a method that will explicitly shut down the ExecutorService
This method passes an invalid constant value to a method parameter that expects only a select number of possible values. This is likely going to cause this method to fail to operate correctly.
This class makes use of internal API classes. As these classes are not documented, nor externally released as part of the API, they are subject to change or removal. You should not be using these classes.
Packages that shouldn't be used are:This method fetches an HttpServletRequest parameter with a parameter name that was used in other locations but with a different casing. As HttpServletRequest parameters are case-sensitive, this will be very confusing.
This method sets or gets an HttpSession attribute with a parameter name that was used in other locations but with a different casing. As HttpSession attribute are case-sensitive, this will be very confusing.
This class, which has instance fields, has no hashCode() method. It is possible that this class is never used in a context where this is required; it is often assumed, however, from clients of this class that it is, so it is good to add such methods when you create them.
This class, which has instance fields, has no equals(Object o) method. It is possible that this class is never used in a context where this is required; it is often assumed, however, from clients of this class that it is, so it is good to add such methods when you create them.
This class, which has instance fields, has no toString() method, which will make debugging with this class more difficult than it could be. Consider adding a toString() method. Using libraries like commons-lang3 ToStringBuilder makes this process easy.
This class has been given a name that does not start with an upper case letter. Classes should follow a pattern of uppercasing the first letter of each word, AsAnExample
This class is defined within a package that uses upper case letters. Package names are expected to be in the form of all lowercase.
This class has been created in the default package. Classes should be defined in a proper package structure, typically defined by the reverse of the domain name of the owner of the code base. Putting code in the default (no) package limits its usefulness, including:
This class defines fields in an order that is confusing, and not expected by other developers. The standard is for static fields to be listed first, followed by instance fields. When fields are listed out of order, developers may make assumptions about their behaviour that are incorrect and lead to bugs.
This method prints a stack trace to the console. This is non configurable, and causes an application to look unprofessional. Switch to using loggers so that users can control what is logged and where.
This method appears to have been generated from an interface or superclass using an IDE. As such the IDE generated generic names (arg0, arg1, arg2) for parameters for this method, and the author of this method did not change them to be meaningful. For better understandability it is recommended that you name these parameters with regard to their function.
This method copies data from input to output using streams or reader/writers using a well known copy method, from java.nio, commons-io, springframework, guava or poi. These methods are efficient in that they copy these files using buffers. However, this method is also buffering the streams, causing a double buffering to occur. So data first goes to one buffer, then is copied to another buffer, before making it to the destination (or vice-versa). This just causes the copy operation to be inefficient both from a time perspective and a memory allocation one. When using these copy methods, do not pass buffered streams/readers/writers.
This method copies data from a java.io.Reader derived class to an output class, using a bulk copy method supplied by java.nio, commons-io, springframework, guava or poi. Since you are copying the entire stream, you don't care about its contents, and thus using a Reader is wasteful, as a reader has to do the hard work of converting byte data to characters, when there is no need to do this. Use stream based inputs for better performance.
This method creates and uses a java.io.FileInputStream or java.io.FileOutputStream object. Unfortunately both of these classes implement a finalize method, which means that objects created will likely hang around until a full garbage collection occurs, which will leave excessive garbage on the heap for longer, and potentially much longer than expected. Java 7 introduced two ways to create streams for reading and writing files that do not have this concern. You should consider switching from these above classes to InputStream is = java.nio.file.Files.newInputStream(myfile.toPath()); OutputStream os = java.nio.file.Files.newOutputStream(myfile.toPath());
This method places non-String objects into a Properties object. As the Properties object is intended to be a String to String map, putting non String objects is wrong, and takes advantage of a design flaw in the Properties class by deriving from Hashtable instead of using aggregation. If you want a collection that holds other types of objects, use a Hashtable, or better still newer collections like HashMap or TreeMap.
Don't use properties.put("foo", bar);
Do use properties.setProperty("foo", "bar");
This method uses the inherited method from Hashtable put(String key, Object value) in a Properties object. Since the Properties object was intended to be only a String to String map, use of the derived put method is discouraged. Use the Properties.setProperty method instead.
Don't use properties.put("foo", "bar");
Do use properties.setProperty("foo", "bar");
This method concatenates an empty string with a literal value, in order to convert the literal value into a string. It is more efficient to use String.valueOf() to do the same thing as you do not incur the cost of creating a StringBuffer/Builder and calling methods on it to accomplish this.
This method concatenates the output of a toString() call into a StringBuffer or StringBuilder. It is simpler just to pass the object you want to append to the append call, as that form does not suffer the potential for NullPointerExceptions, and is easier to read.
Keep in mind that Java compiles simple String concatenation to use StringBuilders, so you may see this bug even when you don't use StringBuilders explicitly.
Instead of:
StringBuilder builder = ...; builder.append(someObj.toString()); ... System.out.println("Problem with the object :" + someObj.toString()); StringBuilder builder = ... builder.append(someObj); ... System.out.println("Problem with the object :" + someObj); NullPointerExceptions when someObj is null. This method uses StringBuffer or StringBuilder's append method to concatenate strings. However, it passes the result of doing a simple String concatenation to one of these append calls, thus removing any performance gains of using the StringBuffer or StringBuilder class.
Java will implicitly use StringBuilders, which can make this hard to detect or fix. For example,
StringBuilder sb = new StringBuilder(); for (Map.Entry e : map.entrySet()) { sb.append(e.getKey() + e.getValue()); //bug detected here } StringBuilder sb = new StringBuilder(); for (Map.Entry e : map.entrySet()) { StringBuilder tempBuilder = new StringBuilder(); tempBuilder.append(e.getKey()); tempBuilder.append(e.getValue()); sb.append(tempBuilder.toString()); //this isn't too efficient } StringBuilder, which is completely unnecessary. To prevent this from happening, simply do: StringBuilder sb = new StringBuilder(); for (Map.Entry e : map.entrySet()) { sb.append(e.getKey()); sb.append(e.getValue()); } This method uses the instanceof operator in a series of if/else statements to differentiate blocks of code based on type. If these types are related by inheritance, it is cleaner to just define a method in the base class, and use overridden methods in these classes.
This method calls algorithmic operations on a String that was returned from a toString() method. As these methods are for debugging/logging purposes, it shouldn't be the basis of core logic in your code.
This class is defined to be a JPA Entity, and has an @Id field that is generated by the JPA provider. Since you do not control when that Id is created directly, it is risky to implement hashCode/equals for this class, and especially for use with Collections, as the data behind the algorithms will not be immutable, and thus cause problems when those fields change, and the object is in the collection. It is usually safer to not define hashCode and equals for entity objects, but treat them as objects for IdentityHashSet/Maps instead.
This method call is to a method that has a @Transactional annotation on it. However, since this call is from the same class, it is not going through any Spring proxy, and thus the transactional quality of this method is completely lost. @Transactional methods must always be called through a Spring bean that is autowired.
This method declares that it either rolls back or does not rollback a transaction based on an expected exception being thrown. However, neither this exception, nor any derived exceptions can be thrown from this method, and so the annotation is useless.
This method declares that it throws one or more non-runtime exceptions. It also is annotated with a @Transactional annotation but fails to describe whether to rollback the transaction or not based on this thrown exception. Use 'rollbackFor' or 'noRollbackFor' attributes of the Transactional annotation to document this.
This method specifies a Spring @Transactional annotation but the method is defined as being non-public. Spring only creates transactional boundaries on methods that are public, and so this annotation is not doing anything for this method. Make the method public, or place the annotation on a more appropriate method.
This method calls EntityManager.merge, and throws away the resultant value. This result is the managed entity version of the potentially unmanaged object that was passed to merge. You should use the returned managed entity for any further use.
This JPA entity specifies a @OneToMany join with a fetch type of EAGER. By default EAGER joins perform select operations on each element returned from the original query in sequence, thus producing 1 + n queries. If you are going to use EAGER joins, it is wise to specify a Join type by using @Fetch annotations in Hibernate or @JoinFetch/@BatchFetch annotations (or hints) in EclipseLink, for example. Even so, these annotations may only apply in limited cases, such as in the use of find.
This method uses JDBC vendor-specific classes and methods to perform database work. This makes the code specific to this vendor, and unable to run on other databases.
This JAX-RS endpoint declares a parameter without specifying where the value of this parameter comes from. You can specify this by using one of several 'Param' annotations (@PathParam, @CookieParam, @FormParam @HeaderParam @MatrixParam @QueryParam), by adding a @Context parameter annotation, or you can declare that the method @Consumes an XML or JSON stream.
This JAX-RS endpoint is annotated to be used with @GET requests, but also documents that it consumes JSON or XML data. Since a GET request pulls parameters from the URL, and not the body of the request, this pattern is problematic. If you wish to consume JSON or XML data, this request should be annotated with @POST.
This JAX-RS endpoint annotates a parameter with a @Context annotation. This annotation can supply values for the following types:
This JAX-RS endpoint has a @PathParam specified that is not found in the @Path annotation and thus can not determine from where to populate that parameter.
This method catches an exception, and throws a different exception, without incorporating the original exception. Doing so hides the original source of the exception, making debugging and fixing these problems difficult. It is better to use the constructor of this new exception that takes an original exception so that this detail can be passed along to the user. If this exception has no constructor that takes an initial cause parameter, use the initCause method to initialize it instead.
catch (IOException e) { throw new MySpecialException("Failed to open configuration", e); } This method allocates a java.awt.Graphics object but doesn't dispose of it when done. While the garbage collector will clean this up, given that a large number of Graphics objects can be created in a short period of time, it is recommended that you explicitly dispose() of them.
This method uses an integer-based for loop to iterate over a java.util.List, by calling List.get(i) each time through the loop. The integer is not used for other reasons. It is better to use an Iterator instead, as depending on List implementation, iterators can perform better, and they also allow for exchanging of other collection types without issue.
This class defines a static logger as non private. It does so by passing the name of a class such as public static final Logger LOG = LoggerFactory.getLogger(Foo.class);
It is recommend to define static loggers as private, and just redefine a new logger in any class that you need to have logging done.
If you wish to have a base class define the logger, and have derived classes use that logger, you can potentially use instance based logging, such as protected final Logger LOG = LoggerFactory.getLogger(getClass());
This constructor declares a parameter that is a Logger. As loggers are meant to be created statically per class, it doesn't make sense that you would pass a Logger from one class to another. Declare the Logger static in each class instead.
This method attempts to use an SLF4J or Log4j2 logger to log a parameterized expression using formatting anchors. However, SLF4J and Log4j2 use simple non numbered anchors such as {}, rather than anchors with digits in them as the code uses. Thus no parameter replacement will occur.
This pattern is invalid: LOGGER.error("{0} is broken", theThing); Use instead LOGGER.error("{} is broken", theThing);
This method attempts to use an SLF4J or Log4j2 logger to log a parameterized expression using String.format notation. However, SLF4J and Log4j2 uses simple non numbered anchors such as {}, rather than anchors with percent signs in them as the code uses. Thus no parameter replacement will occur.
This pattern is invalid: LOGGER.error("%s is broken", theThing); Use instead LOGGER.error("{} is broken", theThing);
This method passes a standard exception as a logger parameter, and expects this exception to be substituted in an SLF4J or Log4j style parameter marker '{}'. This marker will not be translated as SLF4J and Log4j2 don't process the Exception class for markers.
This method uses parameterized logging to avoid the cost of string concatenation in the case that the log level does not meet the needed level. However, one or more of the parameters passed to the logging method uses .toString() to present a String representation for the parameter. This is unneeded as the logger will do this for you, and because it is explicitly done, will always be called even if the log statement is not actually written. Also, by dropping the '.toString()' you may avoid unnecessary NPEs. Just pass the variable as a parameter instead.
This method passes an exception as the first argument to a logger method. The stack trace is potentially lost due to the logger emitting the exception using toString(). It is better to construct a log message with sufficient context and pass the exception as the second argument to capture the stack trace.
This method uses an SLF4J or Log4j2 logger to log a string, where the first (format) string is created using concatenation. You should use {} markers to inject dynamic content into the string, so that String building is delayed until the actual log string is needed. If the log level is high enough that this log statement isn't used, then the appends will never be executed.
This method passes the wrong number of parameters to an SLF4J or Log4j2 logging method (error, warn, info, debug) based on the number of anchors {} in the format string. An additional exception argument is allowed if found.
This method uses an SLF4J or Log4J2 logger to log a string which was produced through a call to String.format, where the format string passed was a constant string containing only simple format markers that could be directly handled by SLF4J or Log4J. Rather than doing
logger.error(String.format("This %s is an error", s)); do logger.error("This {} is an error", s);
This method creates a Logger by passing in a specification for a class that is unrelated to the class in which the logger is going to be used. This is likely caused by copy/paste code.
This method uses a logger method that takes an exception, and passes the result of the exception's getMessage() method as the log message. Since you are already passing in the exception, that message is already present in the logs, and by passing it in as the message, you are just stuttering information. It would be more helpful to provide a handwritten message that describes the error in this method, possibly including the values of key variables.
This line is in the form of
String str = ... str.equals("someOtherString"); //or str.compareTo("someOtherString");A NullPointerException may occur if the String variable str is null. If instead the code was restructured to
String str = ... "someOtherString".equals(str); //or "someOtherString".compareTo(str);equals() or compareTo() on the string literal, passing the variable as an argument, then this exception could never happen as both equals() and compareTo() check for null.This method creates a synchronized collection and stores the reference to it in a local variable. As local variables are by definition thread-safe, it seems questionable that this collection needs to be synchronized.
| If you are using | consider using |
|---|---|
| java.util.Vector | java.util.ArrayList |
| java.util.Hashtable | java.util.HashMap |
| java.lang.StringBuffer | java.lang.StringBuilder |
This method builds a list using Arrays.asList(foo), passing in a single element. Arrays.asList needs to first create an array from this one element, and then build a List that wraps this array. It is simpler to use Collections.singletonList(foo), which does not create the array, and produces a far simpler instance of List. Since both of these arrays are immutable (from the List's point of view) they are equivalent from a usage standpoint.
There is one difference between Array.asList and Collections.singletonList that you should be mindful of. The rarely used set(index, value) method is allowed to be used with a List created by Array.asList, but not with Collections.singletonList. So if you do use the set(index, value) method continue using Arrays.asList.
This method creates a temporary list using Collections.singletonList, or Arrays.asList with one element in it, and then turns around and calls the addAll() method on another collection. Since you are only adding one element to the collection, it is simpler to just call the add(object) method on the collection you are using and by pass creating the intermediate List.
This method fetches the first item in a List using collection streaming. As a list is already ordered there is no need to do that, just use the regular get(0) interface.
Example: String s = myList.stream().findFirst().get();
String s = myList.get(0);
This method copies data from one array to another manually using a loop. It is much better performing to use System.arraycopy as this method is native.
Manual thread scheduling with Thread.sleep() or Thread.yield() has no guaranteed semantics and is often used to mask race conditions. These methods exist for supporting early processors when java was first released, and are not advised for modern processors. The operating system will take care of yielding threads for you.
This method calls equals() to compare two java.math.BigDecimal numbers. This is normally a mistake, as two BigDecimal objects are only equal if they are equal in both value and scale, so that 2.0 is not equal to 2.00. To compare BigDecimal objects for mathematical equality, use compareTo() instead.
Condition.signalAll() is preferred over Condition.signal(). Calling signal() only wakes up one thread, meaning that the thread woken up might not be the one waiting for the condition that the caller just satisfied.
In JDK 1.5 or less, the SecureRandom() constructors and SecureRandom.getSeed() method are recommended against using. Call SecureRandom.getInstance() and SecureRandom.getInstance().generateSeed() instead.
Do not call InetAddress.getLocalHost() on multihomed servers. On a multihomed server, InetAddress.getLocalHost() simply returns the IP address associated with the server's internal hostname. This could be any of the network interfaces, which could expose the machine to security risks. Server applications that need to listen on sockets should add configurable properties to define which network interfaces the server should bind.
Do not use the Locale.setDefault() method to change the default locale. It changes the JVM's default locale for all threads and makes your applications unsafe to threads. It does not affect the host locale. Since changing the JVM's default locale may affect many different areas of functionality, this method should only be used if the caller is prepared to reinitialize locale-sensitive code running within the same Java Virtual Machine, such as the user interface.
Calling Runtime.exit() or Runtime.halt() shuts down the entire Java virtual machine. This should only be done in very rare circumstances. Such calls make it hard or impossible for your code to be invoked by other code. Consider throwing a RuntimeException instead.
Random() constructor without a seed is insecure because it defaults to an easily guessable seed: System.currentTimeMillis(). Initialize a seed like new Random(SecureRandom.getInstance("SHA1PRNG").nextLong()) or replace Random() with SecureRandom.getInstance("SHA1PRNG") instead. "SHA1PRNG" is the random algorithm supported on all platforms.
As of Java 6, you may use new Random(new SecureRandom().nextLong()) or new SecureRandom() instead.
Do not use the ServerSocket constructor or ServerSocketFactory.createServerSocket() factory methods that accept connections on any network interface. By default, an application that listens on a socket will listen for connection attempts on any network interface, which can be a security risk. Only the long form of the ServerSocket constructor or ServerSocketFactory.createServerSocket() factory methods take a specific local address to define which network interface the socket should bind.
The behavior of the String(byte[] bytes) and String.getBytes() is undefined if the string cannot be encoded in the platform's default charset. Instead, use the String(byte[] bytes, String encoding) or String.getBytes(String encoding) constructor which accepts the string's encoding as an argument. Be sure to specify the encoding used for the user's locale.
As per the Java specifications, "UTF-8", "US-ASCII", "UTF-16" and "ISO-8859-1" will all be valid encoding charsets. If you aren't sure, try "UTF-8".
New in Java 1.7, you can specify an encoding from StandardCharsets, like StandardCharsets.UTF_8. These are generally preferrable because you don't have to deal with UnsupportedEncodingException.
Calling Lock.tryLock() or ReentrantLock.tryLock() without a timeout does not honor the lock's fairness setting. If you want to honor the fairness setting for this lock, then use tryLock(0, TimeUnit.SECONDS) which is almost equivalent (it also detects interruption).
Calling one of the following methods without timeout could block forever. Consider using a timeout to detect deadlocks or performance problems. Methods:
Calling ReentrantLock.isLocked() or ReentrantLock.isHeldByCurrentThread() might indicate race conditions or incorrect locking. These methods are designed for use in debug code or monitoring of the system state, not for synchronization control.
Manually triggering finalization can result in serious performance problems and may be masking resource cleanup bugs. Only the garbage collector, not application code, should be concerned with finalization.
Getting or setting thread priorities is not portable and could cause or mask race conditions.
This class 'overloads' the same method with both instance and static versions. As the use of these two models is different, it will be confusing to the users of these methods.
This private or static method only returns one constant value. As this method is private or static, its behavior can't be overridden, and thus the return of a constant value seems dubious. Either the method should be changed to return no value, or perhaps another return value was expected to be returned in another code path in this method.
This method attempts to modify a collection that it got from a source that could potentially have created an immutable collection, through Arrays.asList, Collections.unmodifiableXXX, or one of Guava's methods. Doing so will cause an exception, as these collections are not mutable.
This method calls mySet.keySet().contains("foo") when mySet.containsKey("foo") is simpler.
This method calls size on the keySet(), entrySet() or values() collections of a Map. These sub collections will have the same size as the base Map and so it is just simpler to call size on that Map. Calling size() on one of these sub collections will causes unnecessary allocations to occur.
This method checks for the presence of a key in a map using containsKey(), before attempting to fetch the value of the key using get(). This equates to doing two map lookups in a row. It is much simpler to just fetch the value with get, and checking for non null instead.
As an example, instead of using convert this to Map
Map
The only caveat to this is that if you use a null value in a map to represent a third state for the key, then in this case using containsKey is 'correct'. This means an entry found in the map with a null value is taken differently than no entry at all. However, this is a very subtle programming paradigm, and likely to cause problems. If you wish to mark an entry as not being present, it is better to use a named 'sentinel' value to denote this, so instead of: convert this to Map
Map
This method fetches the value of an entry in a map using get(K k), and then follows it up with a remove(K k). Since a remove() also returns the value, there is no point for doing the get, and just causes two map lookups to occur when it can be done with just one.
As an example, instead of using convert this to Map
Map
This method passes a String to a wrapped primitive object's parse method, which in turn calls the valueOf method to convert to a boxed primitive. When it is desired to convert from a String to a boxed primitive object, it is simpler to use the BoxedPrimitive.valueOf(String) method.
Instead of something like:
Boolean bo = Boolean.valueOf(Boolean.parseBoolean("true")); Float f = Float.valueOf(Float.parseFloat("1.234")); Boolean bo = Boolean.valueOf("true"); Float f = Float.valueOf("1.234"); This method passes a String to a wrapped primitive object's valueOf method, which in turn calls the boxedValue() method to convert to a primitive. When it is desired to convert from a String to a primitive value, it is simpler to use the BoxedPrimitive.parseBoxedPrimitive(String) method.
Instead of something like:
public int someMethod(String data) { long l = Long.valueOf(data).longValue(); float f = Float.valueOf(data).floatValue(); return Integer.valueOf(data); // There is an implicit .intValue() call } public int someMethod(String data) { long l = Long.parseLong(data); float f = Float.parseFloat(data); return Integer.parseInt(data); } This method constructs a Boxed Primitive from a primitive only to call the primitiveValue() method to cast the value to another primitive type. It is simpler to just use casting.
Instead of something like:
double someDouble = ... float f = new Double(someDouble).floatValue(); int someInt = ... byte b = new Integer(someInt).byteValue(); double someDouble = ... float f = (float) someDouble; int someInt = ... byte b = (byte)someInt; This method constructs a Boxed Primitive from a primitive only to call the primitiveValue() method to convert it back to a primitive. Just use the primitive value instead.
Instead of something like:
boolean bo = new Boolean(true).booleanValue(); float f = new Float(1.234f).floatValue(); boolean bo = true; float f = 1.234f; This method assigns a Boxed boolean constant to a primitive boolean variable, or assigns a primitive boolean constant to a Boxed boolean variable. Use the correct constant for the variable desired. Use
boolean b = true; boolean b = false; Boolean b = Boolean.TRUE; Boolean b = Boolean.FALSE; Be aware that this boxing happens automatically when you might not expect it. For example,
Map statusMap = ... public Boolean someMethod() { statusMap.put("foo", true); //the "true" here is boxed return false; //the "false" here is boxed } Map statusMap = ... public Boolean someMethod() { statusMap.put("foo", Boolean.TRUE); return Boolean.FALSE; } This method passes a primitive value retrieved from a BoxedPrimitive.parseBoxedPrimitive("1") call to the same class's constructor. It is simpler to just pass the string to the BoxedPrimitive constructor or, better yet, use the static valueOf.
Instead of something like:
Boolean bo = new Boolean(Boolean.parseBoolean("true")); Float f = new Float(Float.parseFloat("1.234")); Boolean bo = new Boolean("true"); Float f = new Float("1.234"); Boolean bo = Boolean.valueOf("true"); Float f = Float.valueOf("1.234"); This method passes a wrapped primitive object to the same class's constructor. Since wrapper classes are immutable, you can just use the original object, rather than constructing a new one. This code works because of an abuse of autoboxing.
This method passes a wrapped primitive object to the same class' valueOf method. Since wrapper classes are immutable, you can just use the original object, rather than calling valueOf to create a new one. This code works because of an abuse of autoboxing.
This method makes calls to collection classes where the method is not defined by the Collections interface, and an equivalent method exists in the interface. By using the new methods, you can define this object by the Collections interface and allow better decoupling.
This method implements the Serializable interface by performing the same operations that would be done if this method did not exist. Since this is the case, this method is not needed.
This serializable class defines a field as both transient and final. As transient fields are not serialized across the stream, it is required that some piece of code reinitialize that field when it is deserialized. But since constructors aren't called when deserializing, the field is not initialized. And since the field is final, no other method can initialize it either.
This method calls a method to load a reference to an object, and then only uses it to load a static member of that instance's class. It is simpler and more performant to just load the static field from the class itself.
This class defines a private collection member as synchronized. It appears, however, that this collection is only modified in a static initializer, or constructor. As these two areas are guaranteed to be thread safe, defining this collection as synchronized is unnecessary and a potential performance bottleneck.
This method uses a synchronize block where the object that is being synchronized on, is not owned by this current instance. This means that other instances may use this same object for synchronization for their own purposes, causing synchronization confusion. It is always cleaner and safer to only synchronize on private fields of this class. Note that 'this' is not owned by the current instance, but is owned by whomever assigns it to a field of its class. Synchronizing on 'this' is also not a good idea.
This method ignores the return value of a common method that is assumed to be non-mutating. If this method does in fact not modify the object it is called on, there is no reason to call this method, and it can be removed.
This tag library class implements an attribute whose associated backing store field is modified at another point in the tag library. In order for a tag library to be recycleable, only the container is allowed to change this attribute, through the use of the setXXX method of the taglib. By modifying the value programmatically, the container will not initialize the attribute correctly on reuse.
This class implements an equals method that compares this object against another type of object. This is almost always a bad thing to do, but if it is to be done, you must make sure that the basic symmetry rule of equivalence is maintained, that being if a equals b, then b equals a. It does not appear that the class that is being compared to this class knows about this class, and doesn't compare itself to this.
Here's an example of a BAD equals method, do NOT do this:
class Person { public boolean equals(Object o) { if (o instanceof Person) { return name.equals(((Person) o).name); } else if (o instanceof String) { return name.equals(o); } return false; } } This method casts the right hand side of an expression to a class that is more specific than the variable on the left hand side of the assignment. The cast only has to be as specific as the variable that is on the left. Using a more specific type on the right hand side just increases cohesion.
This method uses concrete classes for parameters when only methods defined in an implemented interface or superclass are used. Consider increasing the abstraction of the interface to make low impact changes easier to accomplish in the future.
Take the following example:
private void appendToList(ArrayList<String> list) { if (list.size() < 100) { list.add("Foo"); } } ArrayList, which is a concrete implementation of the List interface. Specifying ArrayList is unnecessary here, because we aren't using any ArrayList-specific methods (like ensureCapacity() or trimToSize()). Instead of using the concrete definition, it is better to do something like: private void appendToList(List<String> list) { ... LinkedList is used instead, this code won't have to change. IDEs tend to have tools to help generalize parameters. For example, in Eclipse, the refactoring tool Generalize Declared Type helps find an appropriate level of concreteness.
This method uses concrete classes for parameters when only methods defined in an implemented interface or superclass are used. Consider increasing the abstraction of the interface to make low impact changes easier to accomplish in the future.
Take the following example:
private void appendToList(ArrayList<String> list) { if (list.size() < 100) { list.add("Foo"); } } ArrayList, which is a concrete implementation of the List interface. Specifying ArrayList is unnecessary here, because we aren't using any ArrayList-specific methods (like ensureCapacity() or trimToSize()). Instead of using the concrete definition, it is better to do something like: private void appendToList(List<String> list) { ... LinkedList is used instead, this code won't have to change. IDEs tend to have tools to help generalize parameters. For example, in Eclipse, the refactoring tool Generalize Declared Type helps find an appropriate level of concreteness.
This method creates a DOM node but does not attach it to a DOM document.
This method compares an Optional reference variable against null. As the whole point of the Optional class is to avoid the null pointer exception, this use pattern is highly suspect. The code should always make sure the Optional reference is valid, and should count on the APIs of this class to check for the held reference instead.
This method creates an Optional object to hold an int, double or long. In these cases it is more natural to use the Optional variants OptionalInt, OptionalDouble and OptionalLong.
This method uses the Optional.orElseGet() method passing in a simple variable or constant value. As this value takes no time to execute and causes no side effects, the use of Optional.orElseGet is unnecessary and potentially confusing. You can use Optional.orElse() instead.
This method uses the Optional.orElse() method passing in some code that will execute immediately, whether or not the else case of the Optional is needed. This may cause incorrect side effects to happen, or at the minimum, code to execute for no reason. It would be better to use Optional.orElseGet()
This method uses Optional.orElseGet(null). This method is supposed to to receive a lambda expression for what to execute when the Optional is not there. If you want to just return null, use Optional.orElse(null) instead.
This method is declared more permissively than the code is using. Having this method be more permissive than is needed limits your ability to make observations about this method, like parameter usage, refactorability, and derivability. It is possible that this detector will report erroneously if:
This method allocates an object using the default constructor in a loop, and then only uses it in a quasi-static way. It is never assigned to anything that lives outside the loop, and could potentially be allocated once outside the loop. Often this can be achieved by calling a clear() like method in the loop, to reset the state of the object in the loop.
This constructor makes a call to a non-final method. Since this method can be overridden, a subclass' implementation will be executing against an object that has not been initialized at the subclass level. You should mark all methods called from the constructor as final to avoid this problem.
This method defines parameters at a more abstract level than is actually needed to function correctly, as the code casts these parameters to more concrete types. Since this method is not derivable, you should just define the parameters with the type that is needed.
This method implements Serializable but is derived from a class that does not. The superclass has fields that are not serialized because this class does not take the responsibility of writing these fields out either using Serializable's writeObject method, or Externalizable's writeExternal method. Therefore when this class is read from a stream, the superclass fields will only be initialized to the values specified in its default constructor. If possible, change the superclass to implement Serializable, or implement Serializable or Externalizable methods in the child class.
This class appears to maintain two or more lists or arrays whose contents are related in a parallel way. That is, you have something like:
List<String> words = new ArrayList<String>(); List<Integer> wordCounts = new ArrayList<String>(); Consider creating a separate class to hold all the related pieces of information, and adding instances of this class to just one list or array, or if just two values, use a Map to associate one value with the other like:
private class WordAndCount{public String word; public int count} List<WordAndCount> wordsAndCounts = new ArrayList<WordAndCount>(); //or, for just two elements Map wordCounts = new HashMap(); This ThreadLocal field is defined as being instance based (not static). As all ThreadLocal variables describe permanent reachability roots so far as the garbage collector is concerned, these variables will never be reclaimed (so long as the Thread lives). Since this ThreadLocal is instanced, you potentially will be creating many non-reclaimable variables, even after the owning instance has been reclaimed. It is almost a certainty that you want to use static based ThreadLocal variables.
This class defines static fields that are Collections, StringBuffers, or StringBuilders that do not appear to have any way to clear or reduce their size. That is, a collection is defined and has method calls like
{add(), append(), offer(), put(), ...}
with no method calls to removal methods like
{clear(), delete(), pop(), remove(), ...}
This means that the collection in question can only ever increase in size, which is a potential cause of memory bloat.
If this collection is a list, set or otherwise of static things (e.g. a List>String> for month names), consider adding all of the elements in a static initializer, which can only be called once:
private static List<String> monthNames = new ArrayList<String>(); static { monthNames.add("January"); monthNames.add("February"); monthNames.add("March"); ... } This field, although defined as a simple variable (int, String, etc), only has a set of constant values assigned to it. Thus it appears to be used like an enum value, and should probably be defined as such.
This method makes two consecutive calls to the same method, using the same constant parameters, on the same instance, without any intervening changes to the objects. If this method does not make changes to the object, which it appears it doesn't, then making two calls is just a waste. These method calls could be combined by assigning the result into a temporary variable, and using the variable the second time.
This method allocates a collection using the default constructor even though it is known a priori (or at least can be reasonably guessed) how many items are going to be placed in the collection, and thus needlessly causes intermediate reallocations of the collection.
You can use the constructor that takes an initial size and that will be much better, but due to the loadFactor of Maps and Sets, even this will not be a correct estimate.
If you are using Guava, use its methods that allocate maps and sets with a predetermined size, to get the best chance for no reallocations, such as:
This method allocates a collection using the a constructor that takes a size parameter. However, because Maps and Sets have a loading factor, passing in the exact size you want is an incorrect way to presize the collection, and may still cause reallocations. Since you are using Guava, it is better to use Maps.newHashMapWithExpectedSize(c.size());
Sets.newHashSetWithExpectedsize(c.size());
This method serializes an instance of a non-static inner class. Since this class has a reference to the containing class, this outer class will be serialized as well. This is often not intentional, and will make the amount of data that is serialized much more than is needed. If the outer class is not desired to be serialized, either make the inner class static, or pull it out into a separate "first class" class.
This method uses the reflective setAccessible method to alter the behavior of methods and fields in classes in ways that were not expected to be accessed by the author. Doing so circumvents the protections that the author provided through the class definition, and may expose your application unexpected side effects and problems. This functionality is deprecated in Java 9, and in Java 10 it is expected that this functionality won't work at all.
This method uses reflection to call a method that is defined in java.lang.Object. As these methods are always available, it is not necessary to call these methods with reflection.
This class extends the JComponent GUI control but does not implement the Accessibility interface. This makes this control unable to be processed by screen readers, etc, for people with reading/vision difficulties.
This class passes null to setLayout, which specifies that components are to be laid out using absolute coordinates. This makes making changes for font sizes, etc, difficult as items will not reposition.
This class uses JLabels that do not specify what fields are being labeled. This hampers screen readers from giving appropriate feedback to users. Use the JLabel.setLabelFor method to accomplish this.
This method sets a Component's explicit foreground or background color which may cause difficulty for people with vision problems using this application. Colors should be allowed to be set from the operating system.
This method creates a component and passes a string that was built up from a number of strings through appending multiple strings together. As foreign languages may order phrases differently, this will make translations difficult.
This method creates a component and passes a string literal to the title or label of the component. As this string will be shown to users, it should be internationalizable through the use of a resource bundle.
This class creates a window, and sizes the window using setSize. It is better, for handling font size changes, to use the pack method.
This method creates an array initialized by constants. Each time this method is called this array will be recreated. It would be more performant to define the array as a static field of the class instead.
The clone method stores a value to a member field of the source object. Normally, all changes are made to the cloned object, and given that cloning is almost always considered a read-only operation, this seems incorrect.
This class declares that it implements an interface, but does so by relying on methods supplied by superclasses, even though those superclasses know nothing about the interface in question. If you wish to have the child not implement all the methods of the interface, it would probably be better to declare the superclass as implementing the interface, and if that class does not provide all the methods, then declare that superclass abstract.
This method uses a synchronized collection, built from Collections.synchronizedXXXX, but accesses it through an iterator. Since an iterator is, by definition, multithreading-unsafe, this is a conflict in concept. When using iterators, you should do the synchronization manually.
This class declares that it implements an interface, but does so by relying on methods supplied by superclasses, even though those superclasses know nothing about the interface in question. If you wish to have the child not implement all the methods of the interface, it would probably be better to declare the superclass as implementing the interface, and if that class does not provide all the methods, then declare that superclass abstract.
This compareTo or compare method returns constant values to represent less than, equals, and greater than. However, it does not return each type, or it unconditionally returns a non zero value. Given that comparators are transitive, this seems incorrect.
This method accesses the class object of a class that is already statically bound in this context, with Class.forName. Using Class.forName makes reflection more fragile in regards to code transformations such as obfuscation, and is unneeded here, since the class in question is already 'linked' to this class.
This compareTo or compare method returns constant values to represent less than, equals, and greater than. However, it does not return each type, or it unconditionally returns a non zero value. Given that comparators are transitive, this seems incorrect.
This method fetches a complex object from an HttpSession object, modifies this object, but does not call setAttribute, to inform the application server that this attribute has been changed. This will cause this attribute not to be updated in other servers in a clustered environment, as only changes marked by a call to setAttribute are replicated.
This method creates an object but does not assign this object to any variable or field. This implies that the class operates through side effects in the constructor, which is a bad pattern to use, as it adds unnecessary coupling. Consider pulling the side effect out of the constructor, into a separate method, or into the calling method.
This method builds a conditional expression, for example, in an if or while statement, where the expressions contain both simple local variable comparisons and comparisons on method calls. The expression orders these so that the method calls come before the simple local variable comparisons. This causes method calls to be executed in conditions when they do not need to be, and thus potentially causes a lot of code to be executed for nothing. By ordering the expressions so that the simple conditions containing local variable conditions are first, you eliminate this waste. This assumes that the method calls do not have side effects. If the methods do have side effects, it is probably a better idea to pull these calls out of the condition and execute them first, assigning a value to a local variable. In this way you give a hint that the call may have side effects.
Example:
if ((calculateHaltingProbability() > 0) && shouldCalcHalting) { } if (shouldCalcHalting && (calculateHaltingProbability() > 0) { } This method implements an AWT or Swing listener and performs time consuming operations. Doing these operations in the GUI thread will cause the interface to appear sluggish and non-responsive to the user. Consider using a separate thread to do the time consuming work so that the user has a better experience.
This method retrieves the property of a Java bean, only to use it in the setter for the same property of the same bean. This is usually a copy/paste typo.
This method retrieves the property of a Java bean, only to use it in the setter for the same property of the same bean. This is usually a copy/paste typo.
This method executes SQL queries inside of a loop. This pattern is often inefficient as the number of queries may mushroom in fencepost cases. It is probably more performant to loop over the input and collect the key data needed for the query for all items, and issue one query using an in clause, or similar construct, and then loop over this result set, and fetch all the data at once.
This method calls a method that does not exist, on a class that does not exist in the JDK that this class has been compiled for. This can happen if you compile the class specifying the -source and -target options, and use a version that is before the version of the compiler's JDK.
This method continues with a loop, and does not break out of it, after finding and setting a variable in an if condition based on equality. Since continuing on in the loop would seem to be unlikely to find the item again, breaking at this point would seem to be the proper action.
Example:
int age = 0; for (Person p : people) { if (p.getName().equals("Dave")) { age = p.getAge(); } } This method makes a static method call on an instance reference. For reading comprehension of the code it is better to call the method on the class, rather than an instance. Perhaps this method's static nature has changed since this code was written, and should be revisited.
This method tests a field to make sure it's not null before executing a conditional block of code. However, in the conditional block it reassigns the field. It is likely that the guard should have been a check to see if the field is null, not that the field was not null.
example:
if (name != null) { name = person.getName(); } if (name == null) This method tests a local variable to make sure it's not null before executing a conditional block of code. However, in the conditional block it reassigns the local variable. It is likely that the guard should have been a check to see if the local variable is null, not that the local variable was not null.
example:
if (name != null) { name = person.getName(); } if (name == null) This class defines a static field 'serialVersionUID' to define the serialization version for this class. This field is marked as non private. As the serialVersionUID only controls the current class, and doesn't affect any derived classes, defining it as non private is confusing. It is suggested you change this variable to be private.
This method constructs a StringBuffer or a StringBuilder using the constructor that takes an integer, but appears to pass a character instead. It is probable that the author assumed that the character would be appended to the StringBuffer/Builder, but instead the integer value of the character is used as an initial size for the buffer.
This method appends two literal strings to a StringBuilder back to back. Modern compilers will optimize something like:
public static final string CONST_VAL = "there"; ... String str = "Hello" + " "+ CONST_VAL + " " +"world!"; public static final string CONST_VAL = "there"; ... String str = "Hello there world!"; public static final string CONST_VAL = "there"; ... StringBuilder sb = new StringBuilder("Hello").append(" ").append(CONST_VAL).append(" ").append("world!"); String str = sb.toString(); Simply append your constants with the "+" symbol, don't append them with StringBuilder.append().
This method assigns a value twice in a row in a stuttered way such as a = a = 5; This is most probably a cut and paste error where the duplicate assignment can be removed.
This method calls equals on a StringBuilder or StringBuffer. Surprisingly, these classes do not override the equals method from Object, and so equals is just defined to be == (or same references). This is most likely not what you would like. If you wish to check that the strings have the same characters, you need to call toString() on these object and compare them as Strings.
This method calls the equals(Object) method on an enum instance. Since enums values are singletons, you can use == to safely compare two enum values. In fact, the implementation for Enum.equals does just that.
| This method uses |
| String prop = System.getProperties().getProperty("foo"); |
| instead of simply using |
| String prop = System.getProperty("foo"); |
This method calls intern on a constant string. As constant strings are already interned, this call is superfluous.
This method calls String.format, passing a static string that has no replacement markers (starting with %) as the format string. Thus no replacement will happen, and the format method is superfluous. If parameters were intended, add the appropriate format markers as needed; otherwise, just remove the call to String.format and use the static string as is.
This method calls toString on an object that hasn't overridden the toString() method, and thus relies on the version found in java.lang.Object. This string is just a raw display of the object's class and location, and provides no information about the information of use. You should implement toString in this class.
This method calls toString on a String. Just use the object itself if you want a String.
This method checks a reference for null just before seeing if the reference is an instanceof some class. Since instanceof will return false for null references, the null check is not needed.
This method calls the size() method on a collection and compares the result to zero to see if the collection is empty. For better code clarity, it is better to just use col.isEmpty() or !col.isEmpty().
This method compares two strings with compareToIgnoreCase or equalsIgnoreCase, after having called toUpperCase or toLowerCase on the strings in question. As you are comparing without concern for case, the toUpperCase or toLowerCase calls are pointless and can be removed.
This method calls a converting method like toLowerCase or trim on a String literal. You should make the transformation yourself and use the transformed literal.
For example, instead of :
return "ThisIsAConstantString".toLowerCase().trim(); return "thisisaconstantstring"; toUpperCase() and toLowerCase(). This method calls the toString method on a StringBuffer or StringBuilder, only to call length() on the resulting string. It is faster, and less memory intensive, to just call the length method directly on the StringBuffer or StringBuilder itself.
ToStringBuilder.reflectionToString(this, ToStringStyle.SHORT_PREFIX_STYLE);
This method calls the toCharArray method on a String to fetch an array of characters, only to retrieve one of those characters by index. It is more performant to just use the charAt method.
This method compares a double or float to the constant Double.NaN or Float.NaN. You should use Double.isNaN(d) or Float.isNaN(f) if the variable is a primitive. If using a boxed primitive d.isNaN() or f.isNaN() should be used.
This method calls StringBuilder.append and assigns the results to the same StringBuilder like:
sb = sb.append("foo") StringBuilder is mutable, so this is not necessary. This is also true of StringBuffer.
This method passes a constant negative value as a bit position to a java.util.BitSet. The BitSet class doesn't support negative values, and thus this method call will not work as expected.
This method passes the empty string "" to equalsIgnoreCase or compareToIgnoreCase. As the empty string is not case-sensitive, using equals is simpler. It would be even simpler to do a length() == 0 test.
This method calls the StringBuffer or StringBuilder constructor passing in a constant empty string (""). This is the same as calling the default constructor, but makes the code work harder. Consider passing in a default size instead.
This method expects an array to be passed as one of its parameters, but unfortunately defines the parameter as Object. This invocation of this method does not pass an array and will throw an exception when run.
This method passes a non-calendar object to the java.util.Calendar.after or java.util.Calendar.before methods. Even though these methods take an Object as a parameter type, only Calendar type objects are supported, otherwise false is returned.
This method calls the BigDecimal constructor that takes a double, and passes a literal double constant value. Since the use of BigDecimal is to get better precision than double, by passing a double, you only get the precision of double number space. To take advantage of the BigDecimal space, pass the number as a string.
This method tests a string, and groups null values with real strings, leaving empty strings as another case. That is, FindBugs has detected a structure like:
String a = null, b = "", c = "someString"; String testStr = ...; //one of a, b or c if ({{FLAWED_TEST_LOGIC}}) { // Strings a and c fall into this branch... which is not typical. } else { // String b falls into this branch. } Pattern found is one of the following:
if ((s == null) || (s.length() > 0)) --- did you mean ((s == null) || (s.length() == 0))?if ((s == null) || (s.length() != 0)) -- did you mean ((s == null) || (s.length() == 0))? if ((s != null) && (s.length() == 0)) -- did you mean ((s != null) && (s.length() > 0)) or perhaps ((s == null) || (s.length() == 0))? This method calls trim() on a String without assigning the new string to another variable. It then calls length() or equals() on this trimmed string. If trimming the string was important for determining its length or its equality, it probably should be trimmed when you actually use it. It would make more sense to first trim the String, store the trimmed value in a variable, and then continue to test and use that trimmed string.
This method tests the value of a boolean and uses a ternary operator to return either true or false. The ternary operator is completely unnecessary, just use the original boolean value.
This method attempts to check for null by just referring to the variable name as would be done in C++. This ordinarily would be considered a compile error, except the variable in question is a Boolean, which does an auto unbox to boolean.
if (b && b.booleanValue()) if (Boolean.TRUE.equals(b)) This method calls myList.iterator().next() on a List to get the first item. It is more performant to just use myList.get(0).
This method defines its own version of PI or e and the value is not as precise as the one defined in the constants Math.PI or Math.E. Use these constants instead.
This method calls a method found in a 3rd-party library, which appears to be shaded from another 3rd-party library. This occurs when a jar includes other code that uses tools like the maven shade plugin. It is likely you wanted to use the "first-class" class from the original jar, rather than the class with the shaded package structure, but your IDE pulled in the wrong import.
An example might be, you attempted to use a method from the class:
com.google.common.collect.Sets org.apache.jena.ext.com.google.common.collect.Sets This method declares two try-catch blocks one after another, where each catch block catches the same type of exception. They also throw uniformly the same type of exception. These two catch blocks can be combined into one to simplify the method.
This method invokes the methods wait, notify or notifyAll on a Thread instance. Doing so will confuse the internal thread state behavior, causing spurious thread wakeups/sleeps, because the internal mechanism also uses the thread instance for its notifications.
This method calls a parsing method (indexOf, lastIndexOf, startsWith, endsWith, substring, indexOf) on a String that is a field, or comes from a collection that is a field. This implies that the String in question is holding multiple parts of information inside the string, which would be more maintainable and type safe if that value was a true collection or a first class object with fields, rather than a String.
This method calls the toString() method on an object and stores the value in a field. Doing this throws away the type safety of having the object defined by a Class. Using String makes it very easy to use the wrong type of value, and the compiler will not catch these mistakes. You should delay converting values to Strings for as long as possible, and thus not store them as fields.
This method builds a key for a map, using a StringBuilder, either implicitly or explicitly. This means the type of the key is something more than a String constant, it is a properly formatted String. However, there is no type based verification that all uses of this key will follow this formatting. It is much better to use a proper, simple, bean class that holds two (or more) fields so that it is clear what is expected for key use.
Example
instead of
V v = myMap.get(tableName + "-" + columnName); V v = myMap.get(new ColumnSpec(tableName, columnName)); This method returns an array that was allocated but apparently not initialized. It is possible that the caller of this method will do the work of initializing this array, but that is not a common pattern, and it is assumed that this array has just been forgotten to be initialized.
This method checks to see if an element is not in a set before adding it. This is unnecessary as you can just add the item, and if the item exists, it won't add it, otherwise it will.
As an example, instead of using convert this to Set
Set
This method checks to see if an element is in a set before removing it. This is unnecessary as you can just remove the item, and if the item exists, it will return true.
As an example, instead of using convert this to Set
Set
This method calls wait() on a mutex defined in the java.util.concurrent package. These classes define await, instead of wait, and it is most likely that await was intended.
This method declares that it returns a Boolean value. However, the code can return a null value. As this is now three values that can be returned - Boolean.TRUE, Boolean.FALSE, null - you have changed what a Boolean means. It would be clearer to just create a new Enum that has the three values you want, and define that the method returns that type.
This method recursively calls itself as the last statement of the method (Tail Recursion). This method can be easily refactored into a simple loop, which will make it more performant, and reduce the stack size requirements.
This method uses a simple for loop to copy the contents of a set, list, map key/value, array or other collection to another collection. It is simpler and more straightforward to just call the addAll method of the destination collection passing in the source collection. In the case that the source is an array, you can use the Arrays.asList method to wrap the array into a collection.
This method creates a java.time.Instant object by first creating a java.util.Date object, and then calling toInstant() on it. It is simpler to just construct the Instant object directly, say by using {@code Instant.now()} to get the current time, of by using {@code Instant.parse(CharSequence)} to convert a String.
This method creates a java.nio.file.Path object by first creating a java.io.File object, and then calling toPath() on it. It is simpler to just construct the Path object directly, say by using {@code Paths.get(String...)}.
This method adds unrelated objects to a collection or array, requiring careful and brittle data access to that collection. Create a separate class with the properties needed, and add an instance of this class to the collection or array, if possible.
This method passes a constant literal String of length 1 as a parameter to a method, when a similar method is exposed that takes a char. It is simpler and more expedient to handle one character, rather than a String.
Instead of making calls like:
String myString = ... if (myString.indexOf("e") != -1) { int i = myString.lastIndexOf("e"); System.out.println(myString + ":" + i); //the Java compiler will use a StringBuilder internally here [builder.append(":")] ... return myString.replace("m","z"); } Strings with their char equivalents like so: String myString = ... if (myString.indexOf('e') != -1) { int i = myString.lastIndexOf('e'); System.out.println(myString + ':' + i); //the Java compiler will use a StringBuilder internally here [builder.append(':')] ... return myString.replace('m','z'); } This class uses an ordinary set or map collection and uses an enum class as the key type. It is more performant to use the JDK 1.5 EnumSet or EnumMap classes.
This method is longer than 8000 bytes. By default the JIT will not attempt to compile this method no matter how hot it is, and so this method will always be interpreted. If performance is important, you should consider breaking this method up into smaller chunks. (And it's probably a good idea for readability too!)
This method declares a method level template parameter that is not bound by any parameter of this method. Therefore the template parameter adds no validation or type safety and can be removed, as it's just confusing to the reader.
This method allocates an object with new, and then checks that the object is null or non null. As the new operator is guaranteed to either succeed or throw an exception, this null check is unnecessary and can be removed.
This method defines parameters that are never used. As this method is either static or private, and can't be derived from, it is safe to remove these parameters and simplify your method. You should consider, while unlikely, that this method may be used reflectively, and thus you will want to change that call as well. In this case, it is likely that once you remove the parameter, there will be a chain of method calls that have spent time creating this parameter and passing it down the line. All of this may be able to be removed.
This inherited method is defined to return a java.lang.Object. However, the return types returned from this method can be defined by a more specific class or interface. If possible consider changing the return type in the inheritance hierarchy of this method, otherwise the caller of this method will be brittle in handling of the return type.
This method returns two or more unrelated types of objects (Related only through java.lang.Object). This will be very confusing to the code that must call it.
This method is defined to return a java.lang.Object. However, the return types returned from this method can be defined by a more specific class or interface. Since this method is not derived from a superclass or interface, it would be more clear to change the return type of this method.
This method stores the return result in a local variable, and then immediately returns the local variable. It would be simpler just to return the value that is assigned to the local variable, directly.
Instead of the following:
public float average(int[] arr) { float sum = 0; for (int i = 0; i < arr.length; i++) { sum += arr[i]; } float ave = sum / arr.length; return ave; } public float average(int[] arr) { float sum = 0; for (int i = 0; i < arr.length; i++) { sum += arr[i]; } return sum / arr.length; //Change } This method writes to a field of this class. Since this class is seen as a Singleton this can produce race conditions, or cause non-visible changes to other threads, because the field isn't accessed synchronously.
This method uses a StringTokenizer to split up a String and then walks through the separated elements and builds an array from these enumerated values. It is simpler and easier to use the String.split method.
PLEASE NOTE: String.split will return an array of 1 element when passed the empty string, as opposed to using StringTokenizer which returns false on the first hasMoreElements/hasMoreTokens call. So you may need to use:
if (s.length() > 0)
return s.split(";");
return new String[0];
This JUnit 4 test is still using classes from the junit.framework.* package. You should switch them over to the corresponding org.junit.* set of classes, instead.
This JUnit test method has no assertions. While a unit test could still be valid if it relies on whether or not an exception is thrown, it is usually a sign of a weak test if there are no assertions. Consider calling fail after an exception was expected. It is also possible that assertions occur in a called method that is not seen by this detector, but this makes the logic of this test more difficult to reason about.
This method asserts that a primitive value that was autoboxed into a boxed primitive was not null. This will never happen, as primitives are never null, and thus the autoboxed value isn't either.
This method asserts that a value is equal to true or false. It is simpler to just use assertTrue or assertFalse instead.
This method calls assertXXX with two doubles or Doubles. Due to the imprecision of doubles, you should be using the assert method that takes a range parameter that gives a range of error.
This method evaluates a boolean expression and passes that to Assert.assertFalse / Assert.assertTrue. It is better to pass the two values that are being equated to the Assert.assertEquals method so that the JUnit failure method is more descriptive of the intended test.
This method evaluates a boolean expression and passes that to Assert.assertFalse / Assert.assertTrue. It is better to pass the two values that are being equated to the Assert.assertNotEquals method so that the JUnit failure method is more descriptive of the intended test.
This method calls assertXXX passing a constant value as the second of the two values. The assert methods assume that the expected value is the first parameter, and so it appears that the order of values has been swapped here.
This method compares an object's equality to null. It is better to use the Assert.assertNull method so that the JUnit failure method is more descriptive of the intended test.
This method compares an object's inequality to null. It is better to use the Assert.assertNotNull method so that the JUnit failure method is more descriptive of the intended test.
This method uses a Java assert to assure that a certain state is in effect. As this is a JUnit test it makes more sense to either check this condition with a JUnit assert, or allow a following exception to occur.
This method manually loops over a collection, pulling each element out and storing it in an array to build an array from the collection. It is easier and clearer to use the built-in Collection method toArray. Given a collection 'mycollection' of type T, use mycollection.toArray(new T[mycollection.size()]);
This TestNG test method has no assertions. While a unit test could still be valid if it relies on whether or not an exception is thrown, it is usually a sign of a weak test if there are no assertions. Consider calling fail after an exception was expected. It is also possible that assertions occur in a called method that is not seen by this detector, but this makes the logic of this test more difficult to reason about.
This method asserts that a primitive value that was autoboxed into a boxed primitive was not null. This will never happen, as primitives are never null, and thus the autoboxed value isn't either.
This method asserts that a value is equal to true or false. It is simpler to just use assertTrue, or assertFalse, instead.
This method calls assertXXX with two doubles or Doubles. Due to the imprecision of doubles, you should be using the assert method that takes a range parameter that gives a range of error.
This method evaluates a boolean expression and passes that to Assert.assertFalse / Assert.assertTrue. It is better to pass the two values that are being equated to the Assert.assertEquals method so that the TestNG failure method is more meaningful of the intended test.
This method evaluates a boolean expression and passes that to Assert.assertFalse / Assert.assertTrue. It is better to pass the two values that are being equated to the Assert.assertNotEquals method so that the TestNG failure method is more meaningful of the intended test.
This method calls assertXXX passing a constant value as the first of the two values. The assert method assumes that the expected value is the second parameter, and so it appears that the order of values has been swapped here.
This method compares an object's equality to null. It is better to use the Assert.assertNull method so that the TestNG failure method is more descriptive of the intended test.
This method compares an object's inequality to null. It is better to use the Assert.assertNotNull method so that the TestNG failure method is more descriptive of the intended test.
This method uses a Java assert to assure that a certain state is in effect. As this is a TestNG test it makes more sense to either check this condition with a TestNG assert, or allow a following exception to occur.
This JUnit 4 test is still using classes from the junit.framework.* package. You should switch them over to the corresponding org.junit.* set of classes, instead.
This JUnit test method has no assertions. While a unit test could still be valid if it relies on whether or not an exception is thrown, it is usually a sign of a weak test if there are no assertions. Consider calling fail after an exception was expected. It is also possible that assertions occur in a called method that is not seen by this detector, but this makes the logic of this test more difficult to reason about.
This method asserts that a primitive value that was autoboxed into a boxed primitive was not null. This will never happen, as primitives are never null, and thus the autoboxed value isn't either.
This method asserts that a value is equal to true or false. It is simpler to just use assertTrue or assertFalse instead.
This method calls assertXXX with two doubles or Doubles. Due to the imprecision of doubles, you should be using the assert method that takes a range parameter that gives a range of error.
This method evaluates a boolean expression and passes that to Assert.assertFalse / Assert.assertTrue. It is better to pass the two values that are being equated to the Assert.assertEquals method so that the JUnit failure method is more descriptive of the intended test.
This method evaluates a boolean expression and passes that to Assert.assertFalse / Assert.assertTrue. It is better to pass the two values that are being equated to the Assert.assertNotEquals method so that the JUnit failure method is more descriptive of the intended test.
This method calls assertXXX passing a constant value as the second of the two values. The assert methods assume that the expected value is the first parameter, and so it appears that the order of values has been swapped here.
This method compares an object's equality to null. It is better to use the Assert.assertNull method so that the JUnit failure method is more descriptive of the intended test.
This method compares an object's inequality to null. It is better to use the Assert.assertNotNull method so that the JUnit failure method is more descriptive of the intended test.
This method uses a Java assert to assure that a certain state is in effect. As this is a JUnit test it makes more sense to either check this condition with a JUnit assert, or allow a following exception to occur.
This TestNG test method has no assertions. While a unit test could still be valid if it relies on whether or not an exception is thrown, it is usually a sign of a weak test if there are no assertions. Consider calling fail after an exception was expected. It is also possible that assertions occur in a called method that is not seen by this detector, but this makes the logic of this test more difficult to reason about.
This method asserts that a primitive value that was autoboxed into a boxed primitive was not null. This will never happen, as primitives are never null, and thus the autoboxed value isn't either.
This method asserts that a value is equal to true or false. It is simpler to just use assertTrue, or assertFalse, instead.
This method calls assertXXX with two doubles or Doubles. Due to the imprecision of doubles, you should be using the assert method that takes a range parameter that gives a range of error.
This method evaluates a boolean expression and passes that to Assert.assertFalse / Assert.assertTrue. It is better to pass the two values that are being equated to the Assert.assertEquals method so that the TestNG failure method is more meaningful of the intended test.
This method evaluates a boolean expression and passes that to Assert.assertFalse / Assert.assertTrue. It is better to pass the two values that are being equated to the Assert.assertNotEquals method so that the TestNG failure method is more meaningful of the intended test.
This method calls assertXXX passing a constant value as the first of the two values. The assert method assumes that the expected value is the second parameter, and so it appears that the order of values has been swapped here.
This method compares an object's equality to null. It is better to use the Assert.assertNull method so that the TestNG failure method is more descriptive of the intended test.
This method compares an object's inequality to null. It is better to use the Assert.assertNotNull method so that the TestNG failure method is more descriptive of the intended test.
This method uses a Java assert to assure that a certain state is in effect. As this is a TestNG test it makes more sense to either check this condition with a TestNG assert, or allow a following exception to occur.
This method allocates and uses an auto closeable resource. However, it manually closes the resource in a finally block. While this is correct management, it doesn't rely on the idiomatic way available to JDK 7 and above, allows for possible subtle problems, and complicates the reading of code by developers expecting the use of try-with-resources.
Switch to using try with resources, as:
try (InputStream is = getAStream()) { useTheStream(is); } This method defines a parameter list that ends with an array. As this class is compiled with Java 1.5 or better, this parameter could be defined as a vararg parameter instead, which can be more convenient for client developers to use. This is not a bug, per se, just an improvement.
This method catches an exception and generates a new exception of type java.lang.Exception, passing the original exception as the new Exception's cause. If the original Exception was actually a java.lang.Error, this is dubious as you should not be handling errors. If the original exception is a more specific exception, there is no reason to wrap it in a java.lang.Exception; this just obfuscates the type of error that is occurring.
This method creates and throws an exception using a static string as the exceptions message. Without any specific context of this particular exception invocation, such as the values of parameters, key member variables, or local variables, it may be difficult to infer how this exception occurred. Consider adding context to the exception message.
This class has two fields in either itself or a parent class, which autowire (without specialization) the same object for both fields. This is likely caused by a developer just not being aware that the field already is available for your use, and just causes wasted space, and confuses code access to the same object through two different pathways.
This method allocates an object with new, but the class of the object that is being created is marked with a Spring annotation denoting that this class is to be used through an @Autowire annotation. Allocating it with new will likely mean that fields on the class will not be autowired, but instead be null. You should just autowire an instance of this class into the class in question, or if need be, use Spring's getBean(name) method to fetch one.
This class creates and initializes a collection as a field but then never accesses this collection to gain information or fetch items from the collection. It is likely that this collection is left over from a past effort, and can be removed.
This method creates and initializes a collection but then never accesses this collection to gain information or fetch items from the collection. It is likely that this collection is left over from a past effort, and can be removed.