Why is this an issue?

The java.util.function package provides a large array of functional interface definitions for use in lambda expressions and method references. In general it is recommended to use the more specialised form to avoid auto-boxing. For instance IntFunction<Foo> should be preferred over Function<Integer, Foo>.

This rule raises an issue when any of the following substitution is possible:

Current Interface Preferred Interface

Function<Integer, R>

IntFunction<R>

Function<Long, R>

LongFunction<R>

Function<Double, R>

DoubleFunction<R>

Function<Double,Integer>

DoubleToIntFunction

Function<Double,Long>

DoubleToLongFunction

Function<Long,Double>

LongToDoubleFunction

Function<Long,Integer>

LongToIntFunction

Function<R,Integer>

ToIntFunction<R>

Function<R,Long>

ToLongFunction<R>

Function<R,Double>

ToDoubleFunction<R>

Function<T,T>

UnaryOperator<T>

BiFunction<T,T,T>

BinaryOperator<T>

Consumer<Integer>

IntConsumer

Consumer<Double>

DoubleConsumer

Consumer<Long>

LongConsumer

BiConsumer<T,Integer>

ObjIntConsumer<T>

BiConsumer<T,Long>

ObjLongConsumer<T>

BiConsumer<T,Double>

ObjDoubleConsumer<T>

Predicate<Integer>

IntPredicate

Predicate<Double>

DoublePredicate

Predicate<Long>

LongPredicate

Supplier<Integer>

IntSupplier

Supplier<Double>

DoubleSupplier

Supplier<Long>

LongSupplier

Supplier<Boolean>

BooleanSupplier

UnaryOperator<Integer>

IntUnaryOperator

UnaryOperator<Double>

DoubleUnaryOperator

UnaryOperator<Long>

LongUnaryOperator

BinaryOperator<Integer>

IntBinaryOperator

BinaryOperator<Long>

LongBinaryOperator

BinaryOperator<Double>

DoubleBinaryOperator

Function<T, Boolean>

Predicate<T>

BiFunction<T,U,Boolean>

BiPredicate<T,U>

Noncompliant code example

public class Foo implements Supplier<Integer> {  // Noncompliant
    @Override
    public Integer get() {
      // ...
    }
}

Compliant solution

public class Foo implements IntSupplier {

  @Override
  public int getAsInt() {
    // ...
  }
}