OCP Java SE 11 Programmer II Study Guide (Sybex) Possible Errata Chapter 3

[Jesse Silverman]

This is a tiny quibble, which looks like OCD but is something else.

I am working to keep clear in my head which things are methods on the Collection interface implemented by all of our Queue, Deque, List and Set classes, and which things are in the nifty Collections utility class that has lots of great stuff that didn't fit somewhere else, and which are in places like List or Queue...

On page 133 of the Sybex OCP Java SE 11 Programmer II Study Guide, Chapter 3, we currently say, regarding Map's replace() and replaceAll():
"These methods are similar to the Collection version except that a key is involved."

There is a replaceAll() method as of 1.8 specific to the List interface, covered in the earlier section on List-specific methods..

The nifty Collections Utility class also contains a handy method called .replaceAll() which I had forgotten about.  I don't think it is covered in the chapter.

I was pretty sure that there is no method in Collection interface by either name, I went and checked to confirm, there isn't.

A tiny detail, but remembering what methods are found in which class or interface was already something I was trying to remember for the exam...

could we just say "replaceAll() is similar to the Collections version except that a key is involved"?  (or to the List version....which may be the one we mean here)

For trivia buffs, the only other  place we actually have replace() per se is in the StringBuilder and String classes, right?  With fifty shades of overload....

In General: While the API Docs pages gets me to the right animal every time I can remember the name of whatever method I seek, I have been trying to remember what Class or Interface they all belong to, and what import statement is needed as exam-specific prep.

[Jesse Silverman]

2nd quibble on Map Methods:

putIfAbsent() is correctly described on page 133.  Very handy.
The examples show that if a Key is present but associated with a NULL value, the Key will become associated with our new value, and NULL will be returned.

The short description in the table on page 130 states that "Adds value if key is not present and returns NULL.  Otherwise returns existing value."
That does not correctly describe what happens if the Key exists but is associated with a NULL value.
Some people will be studying from the synopsis and not re-reading the whole section.

I first learned the HashMap equivalent from "Learning Perl", where for some reason the Schwartz and company team make the biggest distinction between whether no key matches at all or a key is found but is associated with a NULL value.  I still remember their highly emphasized examples.

The behavior in the summary description could make sense, but is clearly different to the actual API behavior in the case of keys associated with NULL.
To plagiarize the Oracle Docs, "If the specified key is not already associated with a value (or is mapped to null) associates it with the given value and returns null, else returns the current value."
I believe that is the shortest accurate description possible in standard English.

I recall negative reviews of some early Java works as being filled with pointless plagiarisms of Sun Documentation.
I always took it to mean that they were just adding little value, but that it was considered fine to quote verbatim from Sun docs in tutorial and reference materials.
I don't know what Oracle's policy is on quoting verbatim from API docs in commercial material.

But I do know what their policy is on putIfAbsent() for existing keys currently associated with null values.  Stated correctly in the examples section, but not in the summary I am likely to be reviewing off of.  I had taken notes already from the summary table and thought the behavior sounded odd upon review, I checked back to see if my notes were in error.

It is hard for me to write "null" in all lowercase, having spent too much time in C...but there, I did it, twice.

[Jesse Silverman]

My quibbles are multiplying like Tribbles.

The super-handy .merge() method for Maps is beautifully and fully described on pages 134 and 135 of the text.  Very nice.

The short description of it in the table on page 130 has the same ambiguity about what happens if the key is present and associated with a null value that putIfAbsent() did.

Sets value if key not set.  Runs the function if the key is set to determine the new value.  Removes if null.

Namely, it sounds like the supplied function would get called, rather than just applying the new value out of hand without calling the supplied function.
This time I took my study notes from the body of text and not the summary, but noted it while reviewing the table.

I have definitely gotten mock exam questions wrong from misunderstandings at this level of granularity, or I wouldn't waste everyone's time with the posts.

I fully appreciate all the hard work that went into both the functionality that Java provides, and the books I have purchased, but people review from the summaries well after the last time they look at the text, I fear.

[Jesse Silverman]

Last quibble on this section, I am moving on to the next one.

On page 136, the text says:

Next, the exam expects you to know which data structures allow null values.  The data structures that involve sorting do not allow null values.

If I recall correctly, Hashtable which is not on the exam anymore but is listed in the "Real World Scenario" box allowed neither null keys nor null values.
Old Java users might get confused by the brief description, tho the earlier HashMap and TreeMap examples in the text clearly featured null values for values.

More relevantly, I remember seeing a presentation from someone who actually wrote Collections Framework code on some relatively more modern data structures for concurrency, which may or may not be included in Chapter 7 of the book I am currently reading, I'm not up to it yet.
They quipped about how much they (like I) hated null values, and I believe they stated that like old Hashtable, they actually prohibit null values as values, not just as keys, and mentioned they wished none of the Map versions allowed null values to have been set, but it was too late for the classical ones, but now the new ones disallowed null values (not just keys) going forward from square one.  I may or may not be remembering that right, tho.

So there may be some opportunity to be confused by the quote versus say:

TreeSet does not permit null elements.  TreeMap does not permit null keys.

I believe that would cover the restrictions in the Collections classes already treated in scope for the exam, without possibly confusing anyone about the larger picture upon comprehensive review.

EDIT -- p. 162 in the Summary does just exactly that, good show!

I am not going to even go into the fact that some purveyors of tutorial information who would no doubt score very high on the exam themselves are confusing beginners by proudly showing off how you can cleverly wedge null keys into TreeMap and null elements into TreeSet using your cleverly written custom Comparator.  I consider those dudes "Too smart for our own good".

[Jesse Silverman]

I lied.  This really is the last comment on this section, because it is the last line of the section.
I believe it is also out of scope of the exam currently, but I am not sure.
It remains extremely common on programming challenges and interview questions.

In "Real World Scenario -- Older Collections"

Stack Implements Queue.  If you don't need concurrency, use a LinkedList instead.

My experience came more from C++ than Java, but I believe even in Java an ArrayDeque often makes a better performing implementation for Stack.
At the level of an interview question, I think the best one-liner may be "Stack is a legacy class.  Nowadays we use LinkedList or ArrayDeque."

[Campbell Ritchie]

I have a different take on stacks. There isn't an implementation of Stack because there isn't a Stack interface, only a legacy class by that name, which Joshua Bloch says implements a failure of inheritance. And I thinkk there is a failure to provide an interface. I think there is no justification for including stack methods in the Deque interface. A stack ISN'T‑A deque and a deque ISN'T‑A stack.
If there were a stack interface then several classes could implement it without any change to their functionality: the old java.util.Stack, LinkedList, and ArrayDeque. ArrayDeque, as you say, gives the best execution speed.

[Jesse Silverman]

I believe that it was C++ where I was disappointed with the strict limitations placed on the Stack interface.  Well, not an Interface, but its equivalent.

A relatively common problem requirement is that if the Stack contains some element we then pop()/poll(remove() our way down to it and do something, if it does not we stack the one we have in hand and keep going.

I don't remember why I needed to do that, just that I did, more than once.

Using the Stack<> reference, I couldn't do the equivalent of .contains() on it, so I wound up not using the Stack interface at all (I think I could have just maintained two references to the same structure, but it was a while ago).  I wound up using a Deque<> reference instead or something like that and grumbling.

Anyway, there's definitely real use cases where making it impossible to see the contents of the Stack except by .peek()/.element()/.pop()/.remove() or whatever makes your work harder, you either need to maintain a separate reference that is searchable or maintain an out-of-band HashSet with the same values (no worse, because of duplicates!  Maybe a HashMap<> with a count).

So I would love to see a Stack interface that still let me at least see into the Stack to tell if it contained an element or not, even if it is probably much better to not allow you to ever remove anything or add anything except at the top.

When I was doing lots of HackerRank/LeetCode problems in C++ there were definitely ones that would only work if I used a Deque<> backed by a Vector<> (ArrayList<>) and other problems that would time out like that and only succeed if I backed it by a LinkedList<> depending on data and usage characteristics.  Trying to say "which one was better" a priori was a Fool's Errand.

Fortunately, C++/C#/Java all make it relatively easy to switch between these by changing one line of code and re-running everything to see which is actually best for what your program is doing.

Call them Interfaces or something else, coding to Interface instead of Implementation is very powerful.

Too bad, about var, then, no?

[Campbell Ritchie]

Jesse Silverman wrote:. . . if the Stack contains some element we then pop()/poll(remove() our way down to it and do something . . . Using the Stack<> reference, I couldn't do the equivalent of .contains() on it . . .

Not my idea of a true stack; you need some other interface for that. Deque sounds good.

coding to Interface instead of Implementation is very powerful.

Isn't it just.

Too bad, about var, then, no?

Don't understand; I can't see where var comes into it.

[Jesse Silverman]

I love the diamond operator, it reduces annoying redundant typing.
Example:

List< HashMap< String, TreeSet<Integer> > > crazyList = new ArrayList<>();

We now have a nice List<> reference referring to an ArrayList that can hold just what we mean to hold, and nothing else unless unsafe code messes with it.

But if we lazily use var "because we can":

var crazyList = new ArrayList< HashMap< String, TreeSet<Integer> > >;

We have an explicit ArrayList holding the type rather than a more flexible List reference.

I picked a less than great example, because there isn't a lot of call for using some other List rather than ArrayList, but Deque<>, Set<>, etc. would all provide better examples of why we wouldn't want to be passing around a reference to a concrete implementation rather than an interface.

I have already been seeing this in a lot of code I see all over the place online, as everyone gets "var happy" or contracts "LVTitis".

I have been referred to the LVTI style guide in the past, but it seems few people consult it.

The Cert Exams for Java 11 love it because it is a new feature so they got to write lots of stuff about it.
There are tons of questions about when var is legal, but not so many (or any) on when it actually is a good idea and contributes to readability with no drawbacks.

That's what I meant.