• 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
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Jj Roberts
  • Carey Brown
Bartenders:
  • salvin francis
  • Frits Walraven
  • Piet Souris

OCPJP8 errata addition, page 213

 
Greenhorn
Posts: 7
2
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the middle of page 213, the book asks which functional interface would we fill in the blank with to make the code compile. It concludes:

"The only functional interface meeting all three of those criteria is DoubleToIntFunction"

However, that is not the only functional interface that would allow the code to compile. You can also use ToIntFunction<Double> or ToIntFunction<Object>, and the code above will compile.
 
Peter Deak
Greenhorn
Posts: 7
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, on the middle of page 306 there appears to be a word missing in the sentence:

"They made it legal to write Exception in the catch block but really only a limited set of exceptions"

I guess it's meant to be something like:

"They made it legal to write Exception in the catch block but really only mean a limited set of exceptions"
 
Peter Deak
Greenhorn
Posts: 7
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, at the bottom of page 458, it claims that the following code throws an exception:



This doesn't appear to be the case on Windows. When I run this code on java version "1.8.0_74":



I get the output below, with no exception:

 
Peter Deak
Greenhorn
Posts: 7
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, on page 573, answer to question 20. The answer and explanation are correct, but the code would fail to compile even before the reasons given; it contains a try-with-resources statement with no { } block. Instead it has an invalid try { .... }; form.
 
Peter Deak
Greenhorn
Posts: 7
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, on page 563, question 10 explanation.

The answer C is correct, but based on the three argument overload for reduce, it is c1 that would be an int and c2 would be the String. The explanation claims the opposite (that c1 is the String and c2 is the int).
 
author & internet detective
Posts: 40354
819
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
page 213 - You’re right! Have a cow for that really good catch. I wasn’t thinking about autoboxing! Have a cow for that great find!
page 306 - agreed
page 458 - confirmed
page 563 - confirmed
page 573 - yuck. I missed this in a number of places. (Because I create questions by copy/pasting code.)
 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Peter Deak wrote:In the middle of page 213, the book asks which functional interface would we fill in the blank with to make the code compile. It concludes:

"The only functional interface meeting all three of those criteria is DoubleToIntFunction"

However, that is not the only functional interface that would allow the code to compile. You can also use ToIntFunction<Double> or ToIntFunction<Object>, and the code above will compile.



And ToIntFunction<Number>.
 
Jeanne Boyarsky
author & internet detective
Posts: 40354
819
Eclipse IDE VI Editor Java
 
Frenkel Smeijers
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are even more possible solutions:
ToIntFunction
(this gives a compile warning)
ToIntFunction<? super Double>
ToIntFunction<? super Number>
ToIntFunction<? super Object>

ToIntFunction<Serializable>
ToIntFunction<? super Serializable>    

ToIntFunction<Comparable>
ToIntFunction<Comparable<?>>
ToIntFunction<Comparable<Double>>
ToIntFunction<Comparable<? super Double>>
ToIntFunction<Comparable<? extends Double>>
ToIntFunction<Comparable<? extends Number>>
ToIntFunction<Comparable<? extends Object>>

ToIntFunction<? super Comparable>
ToIntFunction<? super Comparable<?>>
ToIntFunction<? super Comparable<Double>>
ToIntFunction<? super Comparable<? super Double>>
ToIntFunction<? super Comparable<? extends Double>>
ToIntFunction<? super Comparable<? extends Number>>
ToIntFunction<? super Comparable<? extends Object>>
 
Jeanne Boyarsky
author & internet detective
Posts: 40354
819
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The errata fix avoids that by saying

DoubleToIntFunction" is not true. It should say "DoubleToIntFunction and ToIntFunction meet all three of these criteria. As does "ToIntFunction"



It doesn't get into all the generic variations.
reply
    Bookmark Topic Watch Topic
  • New Topic