• 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
  • Devaka Cooray
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Junilu Lacar
  • Paul Clapham
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • salvin francis
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

Errata - OCP Java SE 8 Study Guide - Chapter 2  RSS feed

 
Author
Posts: 40
7
Android Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • 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: 39129
723
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • 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: 39129
723
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • 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: 4263
35
  • Likes 2
  • Mark post as helpful
  • send pies
  • 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.
 
All of the world's problems can be solved in a garden - Geoff Lawton. Tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
https://coderanch.com/t/704633/RavenDB-Open-Source-NoSQL-Database
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!