== Why is this an issue? Just as there is little justification for writing your own String class, there is no good reason to re-define one of the existing, standard functional interfaces. Doing so may seem tempting, since it would allow you to specify a little extra context with the name. But in the long run, it will be a source of confusion, because maintenance programmers will wonder what is different between the custom functional interface and the standard one. === Noncompliant code example [source,java] ---- @FunctionalInterface public interface MyInterface { // Noncompliant double toDouble(int a); } @FunctionalInterface public interface ExtendedBooleanSupplier { // Noncompliant boolean get(); default boolean isFalse() { return !get(); } } public class MyClass { private int a; public double myMethod(MyInterface instance){ return instance.toDouble(a); } } ---- === Compliant solution [source,java] ---- @FunctionalInterface public interface ExtendedBooleanSupplier extends BooleanSupplier { // Compliant, extends java.util.function.BooleanSupplier default boolean isFalse() { return !getAsBoolean(); } } public class MyClass { private int a; public double myMethod(IntToDoubleFunction instance){ return instance.applyAsDouble(a); } } ---- ifdef::env-github,rspecator-view[] ''' == Implementation Specification (visible only on this page) === Message * Drop this interface in favor of "XXX". * Make this interface extend "XXX" and remove the functional method declaration. ''' == Comments And Links (visible only on this page) === on 14 Sep 2018, 07:02:32 Michal Domagala wrote: Current implementation: 5.7.0.15470 sonar-java/java-checks/src/main/java/org/sonar/java/checks/StandardFunctionalInterfaceCheck.java does not recognize two well known functional interfaces, Runnable and Callable Link to master \https://github.com/SonarSource/sonar-java/blob/master/java-checks/src/main/java/org/sonar/java/checks/StandardFunctionalInterfaceCheck.java endif::env-github,rspecator-view[]