This finding if often seen in combination with the collection classes. For example if you write a utility method that should check a List whether it is empty or null you could use the following code:

public static boolean isEmptyOrNull(List list)
{
  return list == null || list.isEmpty();
}

This will raise a method needlessly defines parameter with concrete classes finding. The reason is that the methods used in the class are not declared in the List interface itself but in the more general class Collection. So you could easily make the method more general and powerful by changing the type of the argument from List to Collection.

public static boolean isEmptyOrNull(Collection col)
{
  return col == null || col.isEmpty();
}

Now you can use this method for example even to test Sets whether they are empty or null.

This might be not so obvious when dealing with less popular classes than the java collection classes. Is this case it is often necessary to check the inheritance hierarchy of the argument type to be able to dig down the reason of the finding.

There is also one situation where this finder leads to false positives. If you have a generic interface for some kind of data holder lets call it NumericData. Assume this interface defines a toInt() method to get the integer representation of this data type. We have a concrete class Age that implements NumericData. If you now create a method storeAge(Age age) that expects a concrete type Age to persist it in the database as its int representation. The body the method will most likely only use age.toInt(). So since this method is available in the NumericData you will get this finding. Nevertheless you should not change the method to accept any kind of NumericData (storeAge(NumericData age)).