• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Errata - OCP Java SE 8 Study Guide - Chapter 2

 
Author
Posts: 42
7
Android Netbeans IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Small typos I've noticed in Chapter 2 (ebook version)

page 60, in the middle:
"The following is a rewrite of our program to use the Predicate class" -> interface

----------------------------------
page 91, in the middle of the last paragraph:
"...as long as it implements the Food interface" -> extends the Food class


//*** Some other points of interest ***

pages 28 & 35, various places
This one is about certain static features allowed in member and local inner classes. The expression 'static final fields' seems too broad as anything instantiated, computed or evaluated at run time still would flag a compiler error:

Probably should change the wording to "compile-time constants and constant expressions" although it may present another problem as not every reader will recall at once that while String literals are compile-time constants, primitive wrappers are not, so the whole point of this change is likely to go unnoticed…

----------------------------------
page 49, last paragraph before the code example:
"An interface may extend another interface, and in doing so it inherits all of the abstract methods" -> replacing 'abstract' with 'non-static' would account for default methods, as well, to remind the reader that unlike classes, static methods in interfaces are uninheritable and a non-static interface method is permitted to overrride a superinterface's static method. Then again, who would remember such subtleties…

----------------------------------
pages 52 & 53
I wonder just how pedantic can be the exam when asking us what makes an interface functional. "A single abstract method per functional interface" is a good practical rule but, unfortunately, there are edge cases when it isn't true. For example, a sole abstract method that has its public twin in java.lang.Object won't make the interface functional; consequently, an interface with such a method can declare another abstract method (just like java.util.Comparator does with compareTo() and equals()) and still be functional:



----------------------------------
page 64, number 3 at the bottom of the page:
"The compiler will not allow casts to unrelated types." -> except when the LHS is an interface type

----------------------------------
page 77: in the middle of the last paragraph
"Furthermore, the first line of any constructor is a call to a parent constructor with the super() command" -> unless the constructor itself calls its overloaded namesake or includes a call to super().

 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Igor Soudakevitch wrote:Small typos I've noticed in Chapter 2 (ebook version)

page 60, in the middle:
"The following is a rewrite of our program to use the Predicate class" -> interface

----------------------------------
page 91, in the middle of the last paragraph:
"...as long as it implements the Food interface" -> extends the Food class


Agreed. I've added both to the errata

Will reply to the rest later today.
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Igor Soudakevitch wrote://*** Some other points of interest ***

pages 28 & 35, various places
This one is about certain static features allowed in member and local inner classes. The expression 'static final fields' seems too broad as anything instantiated, computed or evaluated at run time still would flag a compiler error:


Luckily for us, the exam isn't so subtle about this point which is why we don't cover it.


Igor Soudakevitch wrote:
page 49, last paragraph before the code example:
"An interface may extend another interface, and in doing so it inherits all of the abstract methods" -> replacing 'abstract' with 'non-static' would account for default methods, as well, to remind the reader that unlike classes, static methods in interfaces are uninheritable and a non-static interface method is permitted to overrride a superinterface's static method. Then again, who would remember such subtleties…


Again, some things are to subtle to be worth covering.

Igor Soudakevitch wrote:
pages 52 & 53
I wonder just how pedantic can be the exam when asking us what makes an interface functional. "A single abstract method per functional interface" is a good practical rule but, unfortunately, there are edge cases when it isn't true. For example, a sole abstract method that has its public twin in java.lang.Object won't make the interface functional; consequently, an interface with such a method can declare another abstract method (just like java.util.Comparator does with compareTo() and equals()) and still be functional:


Single abstract method does not have edge cases for which it isn't true. toString(), equals(), etc are NOT abstract methods. They are implemented by Object which means they are inherited by every single Java class. Mentioning them in an interface does not change that fact. It's also redundant.

Igor Soudakevitch wrote:
page 64, number 3 at the bottom of the page:
"The compiler will not allow casts to unrelated types." -> except when the LHS is an interface type


True. That list is about class casting though. In any case, we cover the interface type scenario where we cover instanceof

Igor Soudakevitch wrote:
page 77: in the middle of the last paragraph
"Furthermore, the first line of any constructor is a call to a parent constructor with the super() command" -> unless the constructor itself calls its overloaded namesake or includes a call to super().


True
 
Enthuware Software Support
Posts: 4803
52
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think we need to realize that there is a big difference between a "definition" and an "explanation". Definitions are precise and complete yet concise, which makes them difficult to understand. It is for this reason that we have books that explain those definitions. A book is essentially an elaboration of definitions and if you pick individual sentences of a book, you will invariably find them incomplete. The statement, ""Furthermore, the first line of any constructor is a call to a parent constructor with the super() command" -> unless the constructor itself calls its overloaded namesake or includes a call to super(). " illustrates this point.

You can't make every sentence of a book complete in itself. If you try to do that, you will end up with the BNF specification!

When you read a book, you have to read the whole thing to get the complete story, not just one sentence or a paragraph.
 
Switching from electric heat to a rocket mass heater reduces your carbon footprint as much as parking 7 cars. Tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic