OCP Java SE 11 Programmer I Study Guide (Sybex) Ch 6 -- possible errata

[Jesse Silverman]

There were two things that jumped out at me in Chapter 6 of the OCP Java SE 11 Programmer 1 Study Guide.

One was about the very tricky subject of Comparator.  I have seen videos from people who have a lot of generally good stuff teaching that incorrectly, as in if you followed their presentation you would get the opposite of what you wanted, which tells me it is tricky.

While the description of it in Chapter 6 wasn't flat-out wrong like that (reversing the polarity of the comparison in terms of sort order or tree placement) it was still a little confusing or ambiguous I thought.

The description in the text reads:

Comparator<Integer> ints = (i1, i2) -> i1 -i2;

The ints comparator uses natural sort order.  If the first number is bigger, it will return a positive number.  Try it.  Suppose we are comparing 5 and 3.  The comparator subtracts 5 - 3 and gets 2.  This is a positive number that means the first number is bigger and we are sorting in ascending order.
" (end of quote from book)
While I agree with the explication that then followed on how to sort descending, i.e. by either reversing s2.compareTo(is) or unary minus negation of the value from s1.compareTo(s2), I found that even after learning Comparator, it was somewhat easy to forget how it works, in terms of occasionally getting the opposite of what one intends.  Having a good mnemonic way to not forget that is important.

Two common ways that Comparator is used are for custom sort orders passed to sort() and for proper element placement in TreeSet or TreeMap.  I feel that some explication that would be easy to remember for those uses would cover "What we need to remember about Comparator for success in life".

The sentence "This is a positive number that means the first number is bigger and we are sorting in ascending order" didn't help me.
For sort(), we can say the comparator is answering the question "I want to sort in ascending order, are you positive I need to swap these two elements?" tho "I want to sort in descending order, are you positive that these two elements should be left as they are?" doesn't have the same ring to it.  I had tentatively memorized the first of those two sayings.

When positioning something in a TreeMap (I am not up to the 816 book yet but have had to do this in real life, interviews, exams, etc.) it is answering the question "Am I positive that the new element should be placed to the right of the node I am looking at?" or do I have that backwards?  I am still desperately seeking a neat mnemonic device...

So, my real goal is to have a short neat way to never get this tricky thing wrong that I see other smart people with significant Java knowledge messing up sometimes.  Please excuse my dear aunt Sally.

I didn't find "This is a positive number that means the first number is bigger and we are sorting in ascending order." to do the trick.  I might have preferred "This is a positive number that means the first number is bigger and since we are sorting in ascending order, sort will need to swap the elements for us" as clearer, but still short of a great mnemonic device.

So I think a neat mnemonic to prevent the not-rare-enough mistakes of inverting comparator definitions from what is intended would be of high value.

Anyway, the other thing is *way* simpler:

On page 236 of the print book, we currently say:
"It turns out the keySet() and values() methods each return a Set."

Wait, values() explicitly returns a Collection (probably a List but I think not officially specified) because it most certainly may, and quite often does, contain duplicates.
If one actually needs a Set of values, one needs to create it from the returned likely chock-full-of-duplicates Collection.

Question 7 even teases us with this, because they posit a mythical .valueSet() as an answer choice to trick us.

Anyway, I love the book, and this chapter, but as a very high percentage of people reading it are going to be taking the 819, I consider it harmful to even casually mention that Map's .values() methods return a Set.
The code example works just fine, because we can .foreach() over a Set or a List equally handily.

As always, thanks for all of your hard work helping people learn this often rather tricky material.

Thanks,
Jesse

[Campbell Ritchie]

Jesse Silverman wrote:. . . the very tricky subject of Comparator. . . .

There is nothing tricky about Comparators. It is object ordering that is tricky.

The ints comparator uses natural sort order. . . .

But it doesn't. Look what happened when I tried that Comparator on JShell:-

My JShell wrote:jshell> Comparator<Integer> ints = (i1, i2) -> i1 -i2;
ints ==> $Lambda$26/0x0000000800ba5450@3d646c37

jshell> ints.compare(2_000_000_000, -2_000_000_000)
$6 ==> -294967296

jshell> ints.compare(5, 3)
$7 ==> 2

You will find some of the pitfalls about ordering in the Java™ Tutorials. That link explains how straight subtraction and negation of the result can both go wrong.

Two common ways that Comparator is used . . .

You should be using Comparators for any type with more than one possible criterion for ordering. If your type has only one possible criterion for ordering, then make the type implement Comparable. A tree can fail to operate correctly if it has to deal with a type whose compareTo() method isn't “consistent with equals()”.

. . . "This is a positive number that means the first number is bigger and we are sorting in ascending order" . . . "I want to sort in ascending order, are you positive I need to swap these two elements?" . . .

If whatever appears on the left is “larger” than whatever appears on the right, you get a positive result. The built‑in sorting methods always sort in ascending order full stop. If you want to sort descending, you will have to pass a Comparator or similar making 3 bigger than 4. Example:-

Comparator intsDescending = (i, j) -> Integer.compare(j, i);
/* swap i and j to make 3 > 4 */

Afraid I don't know any straightforward mnemonics.

. . . "Am I positive that the new element should be placed to the right of the node I am looking at?" . . .

Or simply remember which is bigger and trust the collection's implementation to sort it for you.

. . . values() explicitly returns a Collection (probably a List but I think not officially specified) . . .

Have you tried it? Have you seen what type is returned from Map#values()? It is most unlikely to be a List.

Question 7 . . . posit[s] a mythical .valueSet() . . . to trick us.

The real exam may contain questions requiring such knowledge of the methods in the API.

[Jeanne Boyarsky]

Added the return type of values() one to the errata. Thanks!