Sybex CSG tb617624.JaSE11PrgIISG.be2.68

[Will Easter]

For this question:

Which functional interfaces can fill in the blanks to make the code compile? (Choose all that apply.)

5:    public void doubles(______ x, ________ y, ________ z) {
6:       double d1 = x.applyAsDouble("");
7:       double d2 = y.applyAsDouble(1L);
8:       z.accept(1.0);
9:    }


The answer are:
A. Consumer<Double>
B. DoubleConsumer
C. Function<Long, Double>
D. Function<String, Double>
E. LongToDoubleFunction
F. ToDoubleFunction<String>

I am having a hard time understanding why DoubleConsumer is not acceptable. DoubleConsumer's SAM is accept() and it takes a double.

What am I missing?

Thank you in advance,

Will

[Mikalai Zaikin]

You're right. It seems an error for me.

When in doubt -- try the compiler 8-)

DoubleConsumer dc = ... ;
dc.accept(1.0);
Consumer<Double> c = ... ;
c.accept(1.0);

These both are valid.

[Jesse Silverman]

If you are missing anything, I am missing it to.

For instance, witness this:

jshell> DoubleConsumer z = d -> System.out.println(d );
z ==> $Lambda$20/0x0000000800c09a00@443b7951

jshell> z.accept(1.0);
1.0

jshell> Consumer<Double> zz = d -> System.out.println(d);
zz ==> $Lambda$21/0x0000000800c0aa00@28c97a5

jshell> zz.accept(2.0);
2.0

Auto-boxing and unboxing FTW, but either functional interface can work with either call due to unboxing and auto-boxing...

It is instructive to see why the two answers that really are wrong won't work:
C. Function<Long, Double>
D. Function<String, Double>

The functional interface of Function, regardless of type parameters, does not define a method named applyAsDouble() with any overload at all.
So attempts to call it using that method name will not compile.

The "primitive specializations" for consumer don't need a different name because they aren't returning anything, so they have no need to overload a method on return type (this is why a new name is needed for the primitive specializations for functional interfaces that need to return a value).

They don't need one, they don't have one, calling the same method with a primitive of the appropriate type works just great with auto-boxing as shown above.

Tho the question didn't ask that, notice that the one that is a primitive specialization works when passed a long because primitives can undergo widening conversions, e.g. long --> double
jshell> z.accept(1L);
1.0

whereas it is good to see why this fails (you can't widen and auto-box in one step):
jshell> zz.accept(1L);
|  Error:
|  incompatible types: long cannot be converted to java.lang.Double
|  zz.accept(1L);
|            ^^
Note this question didn't ask that, however.

[Will Easter]

Thank you for quick and prompt replies. I have submitted this Wiley (including asking for a more thorough explanation of why DoubleConsumer is unacceptable). Hopefully, there will be a response.

Regards,

Will

[Jesse Silverman]

Wiley/Sybex doesn't get too involved at the level of individual questions and answers, or book errata.

The authors themselves frequent this forum and should see this in not too long, for now, I think both Mikalai and myself are in agreement with your take on this.

[Jeanne Boyarsky]

Confirmed errata and credited Will on the errata page. Thanks Will!