• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Frits Walraven
Bartenders:
  • Carey Brown
  • salvin francis
  • Claude Moore

Sybex OCP Java 8 Study Guide: p557 query (possible erratum?)  RSS feed

 
Ranch Hand
Posts: 39
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeanne & Scott

A small query about the answer to Review Question 12 of Chapter 4 (p229) on p557: Although I agree that option F (Supplier<String>) is the obvious choice for Line 6, it seems that E (Consumer<String>) and G (UnaryOperator<String>) also compile for it. I realise they’re unlikely to be used that way in practise, but technically they could be, so should E be added to the answer?

For E, I suppose the equivalent lambda is   Consumer<String> x = s -> new String();   and the compiler infers that it should not insert a ‘return’ for the creation expression, which I assume can be regarded as a stand-alone statement rather than just an expression.
For G, I think the lambda would be the same, i.e.   UnaryOperator<String> x = s -> new String();   but this time the compiler infers that the new String is returned.
And this is where I start gibbering and hope the exam doesn’t include too many tricksey ambiguous method refs etc :O

EB
 
Marshal
Posts: 64171
215
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please supply more details of the question for those of us who don't have the book.
 
E Byrne
Ranch Hand
Posts: 39
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Assuming it's OK with the authors, here's the Q:

Which functional interfaces complete the following code? (Choose all that apply.)

6: ____________ x = String::new;
7: ____________ y = (a, b) -> System.out.println();
8: ____________ z = a -> a + a;
A. BiConsumer<String, String>
B. BiFunction<String, String>
C. BinaryConsumer<String, String>
D. BinaryFunction<String, String>
E. Consumer<String>
F. Supplier<String>
G. UnaryOperator<String>
H. UnaryOperator<String, String>

And A:

A, F, G. Line 6 doesn’t take any parameters, and it returns a String, making it a Supplier.
Another clue is that it uses a constructor reference, which should scream Supplier!
This makes choice F correct. Line 7 takes two parameters, and it doesn’t return anything
making it a BiConsumer. The print statement should also be a clue that we are dealing with
a Consumer or BiConsumer. This makes choice A correct. Choices C and D are there to
mislead you; these interfaces don’t actually exist. BinaryOperator spells out binary. The
other functional interfaces use the prefix Bi. Finally, line 8 takes a single parameter, and it
returns the same type, which is a UnaryOperator. Since the types are the same, only one
generic is needed, making choice G correct.
 
Campbell Ritchie
Marshal
Posts: 64171
215
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for the information
Yes, line 6 as a Supplier, line 7 as a BiConsumer and a UnaryOperator for line 8 look right. Is that what the answers given were?
A consumer for line 6? But in that case it wouldn't be able to return a value would it? And a UnaryOperator would require some sort of input, which line 6 doesn't seem to have.
I hope I have got it right
 
E Byrne
Ranch Hand
Posts: 39
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Campbell  

Campbell Ritchie wrote:Thank you for the information
Yes, line 6 as a Supplier, line 7 as a BiConsumer and a UnaryOperator for line 8 look right. Is that what the answers given were?


Yes indeed

A consumer for line 6? But in that case it wouldn't be able to return a value would it?


Agreed, but the instructions didn't specify it had to return the new String or do anything useful, so I suppose I'm thinking like a lawer or somesuch  

And a UnaryOperator would require some sort of input, which line 6 doesn't seem to have.
I hope I have got it right


Not here, but code that used it could.
So I made a small demo...but then the plot thickened off on a weird tangent   ...

 
E Byrne
Ranch Hand
Posts: 39
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In retrospect, I suppose this is not surprising, though - why indeed would the compiler not use the UnaryOperator's input in a constructor that can take it?
 
Campbell Ritchie
Marshal
Posts: 64171
215
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

E Byrne wrote:Thanks Campbell    

That's a pleasure.

. . .

A consumer for line 6? But in that case it wouldn't be able to return a value would it?


Agreed, but the instructions didn't specify it had to return the new String or do anything useful, so I suppose I'm thinking like a lawer or somesuch  

If you call String::new or simlar, that value will be left behind on the stack. That is equivalent to returning a value; that excludes a Consumer, but as you have shown you can actually supply an argument to the apply() method.

. . . So I made a small demo...but then the plot thickened off on a weird tangent   ...  . . .

So you declare that constructor reference as being of type UnaryOperator. Since Java® gives String a copy constructor, your constructor reference has to take the one‑argument form so it can use the apply() method taking one argument.

What an interesting point you have found; I shall add you to a more general forum so as to gain more attention to your question.
 
E Byrne
Ranch Hand
Posts: 39
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks again.
I think my follow-up speculation re the 1-arg constructor overlaps with your explanation, and I'll sleep    on the stack/return thought  
 
Sheriff
Posts: 21719
102
Chrome Eclipse IDE Java Spring Ubuntu VI Editor Windows
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

E Byrne wrote:Another clue is that it uses a constructor reference, which should scream Supplier!


Not necessarily. String::new can also be one of the following, depending on which constructor you want to match:
* Function<String, String>
* Function<char[], String>
* BiFunction<byte[], String, String>
* BiFunction<byte[], Charset, String>
* Function<byte[], String>
* Function<StringBuffer, String>
* Function<StringBuilder, String>
 
E Byrne
Ranch Hand
Posts: 39
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Rob - just for clarification, that line was from the book's answer text which I was quoting per request to supply more details. (In retrospect, perhaps I should have put it in quote tags/format.) I agree with the authors' implication that it might be the most obvious usage, though. I didn't go looking beyond the 2 extra assignments from the question options that I discussed, but your listing indeed demonstrates that are many other possibile functions this method ref could be applied to.
 
Master Rancher
Posts: 3189
119
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Rob
excellent reply!

@OP
Strange is that for line 6 option E is not mentioned. When dealing with a reference, the return value may be discarded. So that means that
(option E) is perfectly okay.
If we had used the parameter version:

then, since the return value is not discarded, we get a compiler error.

Edit: I interpreted the question wrongly. So, consider the above as never written...   sorry!

in addition to what Rob said, the way I tackled questions like this was to replace the method (or constructor) reference by its parameter version. So you would get:

Then, have a look at the String class, what constructors are there for new String(...)? If you do, you get all the things mentioned sofar, but also the funny:

And all that is left to do is to create the interface 'QuadFunction'.

But as I just realized: be careful when you replace references by parameter versions: I would have missed the Supplier thing...

A last remark: that Supplier works here is due to the fact that String has a parameterless constructor.
 
E Byrne
Ranch Hand
Posts: 39
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Piet.

Piet Souris wrote:
... A last remark: that Supplier works here is due to the fact that String has a parameterless constructor.


Indeed, another example being ArrayList::new (returns an empty ArrayList), cf. Integer::new does not compile.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!