Greg Charles

The parent's construction happens before the child's construction.  This means that even though you will be calling the overridden Parent() method from the Parent() constructor, as you pointed out, the id field of the Child instance won't be initialized yet. So when line n8 runs, it sees id = 0, which it decrements and print. After the parent's constructor finishes, the Child's id field will be set to 2000 and the Child instantiation will be complete.

I have to say that making the method have the same name as the class and constructor makes this a lot harder to parse. Never do this in real life. I know that exam questions sometimes do this, but I even disagree with that.

Haha, fair point! I don't know the designers though, and even if I did, they'd probably claim it's not a bug, it's a feature. They are software engineers after all!

The basic Java Stream has overloaded the sorted() method. The no parameter form sorts by the natural order, assuming the underlying stream type is a Comparable. The one-parameter form takes a Comparator and uses that for the sort. However, the min() and max() methods (in the base stream) force you to provide a comparator, and don't have a no parameter form. Why this inconsistency?

Most of the answers I've seen talk about why you don't really need a no parameter form since you can just put in Comparator::naturalOrder, but they ignore the question of why sorted() does have a no parameter form. One person suggested that the no parameter sorted() was just a mistake and it can't be corrected without breaking backward compatibility, but that min() and max() were added later.  Not repeating a mistake was apparently considered more important than internal consistency. Is that the answer?

I guess I'm still not following here. It doesn't seem like the wording is sloppy, but just that the answer key is wrong. You said the behavior won't be deterministic ... I'm with you on that. It doesn't match any of the answers ... yes that's right. It's non-deterministic so it will either commit the insert or roll it back, but there's no way to tell which. One scenario would make the table have one row, and the other would leave the table empty. We're still on the same page up to there. However, "assume the straightforward case," loses me. What is the straightforward case? The answer key says, "D. The table will remain empty," which as far as I can tell isn't any more straightforward than, "E. The table will have one row."

I feel like you flipped a coin and asked whether it came up heads or tails, and because it can't be determined that means the answer is heads. I'm sure I'm missing something, but I just can't figure out what.

Oof, good pushback. Yes, the Java Specification outranks Oracle's Java tutorials. It would be nice if they could stay consistent though, as you note, by saying in the tutorial, "they are like compact, easy-to-read lambda expressions." I guess I'd actually prefer the spec change its wording here: "Unlike other lambda expressions, method references ..." From a broader CS perspective, both lambda expressions and method references are acting as lambdas.

I was interested in the spec's point that method references could be used as a generic factory, whereas a a regular lambda expression couldn't. I hadn't really thought of that before, so it's good to know. That's the one hole in considering method references to just be a special case of lambda expressions.

Jeanne Boyarsky wrote:Either is right. Single file source code execution allows you to pass the .java filename to java if you don't compile.

Oh, shoot. I learned that by reading your study guide, and then I forgot it again. I hope I'll remember it now! It's always going to look like a typo to me though.

OK, here's another one I already know I'm going to get pushback on. This question is about what symbol is required for all lambda expressions. I had -> checked when I said to myself, "Aha, it's a trick. Method references don't have ->." So, I smugly put in "None of the above," but no, the answer actually was ->. Is a method reference not a lambda expression? That's a question of semantics, and I could go either way on it. However, the Oracle Documentation says this:

You use lambda expressions to create anonymous methods. Sometimes, however, a lambda expression does nothing but call an existing method. In those cases, it's often clearer to refer to the existing method by name. Method references enable you to do this; they are compact, easy-to-read lambda expressions for methods that already have a name.

tl;dr Method references ... are ... lambda expressions.

I just noticed a couple of nits here:

Question 15: shows a run command as java Copier.java, but it should just be java Copier.

Question 52: says null can't be inserted into a TreeSet, which is true is in the default case, but not universally true.  If you give the TreeSet a Comparator that can handle nulls, then it's fine to put a null into it.

TreeSet<String> treeSet = new TreeSet<>(Comparator.nullsLast(Comparator.naturalOrder())); treeSet.add("Hello"); treeSet.add(null); System.out.println(treeSet);  // ["Hello", null]

Hi Jeanne,

I may be reading that wrong, but it seems like you are arguing that the answer to this question should be B only. That is, if auto-commit is off and then turned on, then any uncommitted changes are immediately committed, so the table ends up with one row (answer B), but if auto-commit is not turned back on, and no commit or rollback is performed before the connection is closed, then the database state is undefined. That would make D incorrect, since it says the table "will" remain empty after the code runs. E is also incorrect because it says the table "will" contain one row. If either of these statements said "might", then it would be right, but they both say "will". The question says to pick two answers, and the answer key says those are B and D. I can't see how D is right, but E is wrong here.

Now, I'm guessing that most drivers are going to roll-back in this case, so D will usually be correct, but according to the text, that's not always going to be the case.

Review question 21 for chapter 15 has a JDBC connection with auto-commit set to false. In one scenario, the auto-commit is set back to true, which according to the "Edge Cases" blurb on page 894, will cause an immediate commit. The answer key calls this out correctly (answer B)

In the second scenario, the change of auto-commit to true is commented out. According to the same blurb, "... if you have autocommit set to false and close your connection without rolling back or committing your changes ... the behavior is undefined. It may commit or roll back ..." The answer key is consistent with it definitely rolling back (answer D).  

It seems to me the answer should be B and (D or E). Either that or the Edge Case blurb is wrong on this point.

Question 4 of the review question asks which lines would need to be changed for the code to compile, but doesn't call out line  w4:

System.out.println(result.get()); // w4

... where result has type Future. Future.get() throws two checked exceptions and the code snippet doesn't show catching or declaring these exceptions. If we assume the snippet is inside a try-block with an appropriate catch, or is part of a method that declares the exceptions, then it would be fine, but without that assumption, there would be a compile error on that line. That could be clarified a bit.

I'm not sure this rises to the level of an erratum, but the answer key for question 25, starts by saying, "Java does not allow multiple inheritance ...", but then answer C for question 55: "Java does not allow multiple inheritance," is marked as wrong. Now, I would answer the question, "Does Java allow multiple inheritance?" for Java 7 and before with "definitely, no", but from Java 8 and after with "well, sort of". So, nothing in either answer key for questions 25 and 55 is actually wrong -- just kind of driving in both lanes at once.

It's not really print() vs. println() that I"m getting at, but whether text where the last line ends with \n counts as one line longer than an otherwise identical text block that doesn't.

One more thing, and then I'll shut up, because I'm even starting to annoy myself at this point. I swear though, it's just because I don't want to miss a question on the exam by not counting lines the way the exam thinks they should be counted.

       var text = """                ant antelope \s \n                cat "kitten" \                seal sea lion                """;        System.out.print(text);        var lineCount = text.lines().count();        System.out.println("Line count is " + lineCount);


Output:
ant antelope   cat "kitten" seal sea lion Line count is 3

So, Java counts it as 3 lines, not 4 as the answer key states. It doesn't include an extra blank line into the stream after the final \n. However, the comment on the lines() method is ambiguous:

Returns a stream of lines extracted from this string, separated by line terminators.

Are they separators or terminators? Nope, they're terminators that separate. Gah! Yes, I know this matters very little outside of the exam context.

Here's my advice, since there seems no definite answer to whether an implied blank line after a final \n counts or not, if we get a question like this on the exam, let's guess an odd number of lines if we take the exam on an odd day of the month, and even if on an even day. Then we have a 50/50 chance of getting the point and we leave it in the hands of fate. May the mighty Lachesis look kindly upon us.  

Hmm, I'm not following. When does it matter vs. not matter? Actually though, my main issue is will the exam ask "count the number of lines of output" questions, and if it does, is the answer always going to be the number of line separators plus one?

To use my earlier example ...

System.out.println("Hello, world!");

... does that count as two lines of output by the exam's definition? I guess that actually makes sense, since even I have been calling \n a line separator rather than a line ender.

Ah, got it. Anyway, going on to question 38 in the same test, it's clear from the answer key that the way you're counting lines is correct, and my way is wrong. That is, n lines all ending with line terminators should be counted as n + 1 lines of output. This seems bizarre to me, and now I'm wondering if the real test will force counting like this or not.