CallToDeprecatedMethod issues with generic constructor args

Rules and Languages Report False-positive / False-negative...
,
1

I noticed this with version 5.9.2 of the sonar-java plugin.

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class UsesDeprecations {

  public static void test() {
    new HasDeprecations(new ArrayList<>());
    new HasDeprecations(new HashMap<>());
  }

  static class HasDeprecations {
    @Deprecated
    public HasDeprecations(final Map<String, String> m) {}

    public HasDeprecations(final List<String> l) {}
  }
}

Both constructor calls are marked with Remove this use of “HasDeprecations”; it is deprecated. despite only one being deprecated. If I switch which constructor has the @Deprecated annotation, then neither call is detected as deprecated.

I actually ran into this while developing a custom rule that is very similar to CallToDeprecatedMethod, so if there are any workarounds that I can implement in a custom rule I’d be interested to hear them.

2

I noticed if I change the line to
new HasDeprecations(new ArrayList());
or
new HasDeprecations(new ArrayList<String>());
the false-positive HasDeprecations violation goes away. It seems to be specific to the diamond <> operator.

Any ideas?

3

Looks like this doesn’t just affect constructors, but methods as well. This code shows the same issue:

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class UsesDeprecations {

  public static void test() {
    HasDeprecations.method(new ArrayList<>());
    HasDeprecations.method(new HashMap<>());
  }

  static class HasDeprecations {
    @Deprecated
    public static void method(final Map<String, String> m) {}

    public static void method(final List<String> l) {}
  }
}

If the first method is @Deprecated, both calls are marked by CallToDeprecatedMethod (one false positive). If the second method is @Deprecated, neither is marked by CallToDeprecatedMethod (one false negative).

6

hello @bsfarrell,

thanks for reporting this issue and sorry for the late reaction. This is in fact problem in our semantic because methods are not resolved properly. I created ticket for it
https://jira.sonarsource.com/browse/SONARJAVA-3120

We have a plan to rework our semantic engine completely in following months, so this will be probably solved as part of that rework.