Miles Jiang

Greenhorn
+ Follow
since Apr 04, 2021
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Miles Jiang

Campbell Ritchie wrote:
[Edit] Your first code block has four quotes on line 4! I think you have copied it wrongly.



Thanks for the correction. I made a mistake while copying. There should be three quotes instead of four.
Question 60 (page 20) asks how many backslashes in the following code can be removed without changing the value of the text block.



The correct answer is 4 backslashes can be removed (option E), as explained on page 449:

Both backslashes on line 13 can be removed since this is a text block. Additionally, the second and third backslashes on line 14 can be removed. The first one must be retained since there are three quotes in a row.



On line 13, both backslashes can be removed. No doubt about it. On line 14, up to two of the three backslashes can be removed, but at least one must remain. However, does the backslash to be retained have to be the first one? Probably not. According to my running results, the code will compile regardless of which backslash remains.

(1) Keep the first backslash:



(2) Keep the second backslash:



(3) Keep the third backslash:



So should the explanation be adjusted?
Hi there, I found a possible typo in the explanation for Question 42.

42. What is a possible output of the following?



A. 2022-05-13T10:00-07:00[America/Los_Angeles]
B. 2022-05-13T00:00:00Z
C. 2022-05-13T17:00:00Z
D. 2022-05-14T10:00-07:00[America/Los_Angeles]
E. 2022-05-14T00:00:00Z
F. 2022-05-14T17:00:00Z

The answer is option F, which is no problem. But the explanation on Page 448 says:

An Instant represents a specific moment in time using GMT. Since there are no time zones included, options A and C are incorrect. This code correctly adds one day to the instant. It includes the date, making option F correct.



I think the options that include time zones are A and D, not A and C.
Chapter 2, Question # 28: The code contains six pairs of curly braces. How many pairs can be removed without changing the behavior?



Since there is no termination condition or break statement inside the if-else block, the code runs but never ends.

The solution I think is to add "i++;" or "break;" to if and else blocks, respectively:



Now the curly braces of for (lines 3/14) and while (lines 4/13) are optional, while the braces of if-else (lines 5/8 & 8/12), switch (lines 15/17), and the main method (lines 1/18) are required.

If so, the answer to this question should be corrected correspondingly: there are two instead of three pairs of curly braces can be removed. That is, the correct answer is Option B instead of C.

Thanks your explanation @Mikalai and @Jesse. Now I got the point.
OCP Java SE11 Programmer I Study Guide, Page 201, Penultimate paragraph.

When discussing autoboxing into Integer, an example is given:



We want to remove the element 1 but the statement at Line 4 actually removes the element at index 1, which is 2, so what remains is 1 instead of 2. To get the desired result, the book recommend that Line 4 be replaced with numbers.remove(new Integer(1)).

This is one solution, but strictly speaking, Integer(int) has been deprecated since Java 9. So for the sake of rigor, it seems better to use numbers.remove(Integer.valueOf(1)), I guess?

An online compiler like Techie Delight accepts new Integer(1) without any problem, while an IDE like Eclipse will tell you that "The constructor Integer(int) is deprecated since version 9" and provide two quick fixes; one of which is adding @SuppressWarnings "deprecation" to main(). Of course, an IDE also accepts new Integer(1).

(I would note that the introduction of lambdas has made me much more tempted to put braces on the same line for short statements.)
Then too, I am a big fan of using ternary operators like this:



Which may be less "readable"  to people not used to seeing it.  But I find readability is often subjective, and based on what you are used to seeing.  I encourage people to expand their notion of readability to include chained ternary operators, mimicking the else if structure we already accept.



To reduce the number of curly braces, some companies I know require to use of ternary operators instead of if-else statements for all simple conditionals, similar to the example Mike provided above. That is, the following if-else statement is even not accepted in certain companies any more.



To comply with the coding guideline, developers are required to use ternary operators whenever possible.



Another good practice, I guess?

It is an age old problem in programming languages.
https://en.wikipedia.org/wiki/Dangling_else

Specifically, for Java: https://stackoverflow.com/questions/32076762/java-statements-processing-precedence-dangling-else



I guess this illustrates why using curly braces is always a good idea, especially for rookie developers.
Thanks for clarification, Paul. Seems I got the point (correct me if I'm wrong):

1. else statement can't exist alone. If you see an else statement, there must be one (and only one) if statement somewhere before it.

2. if statement can exist alone.

3. So the if -> else if -> else if structure is effectively equivalent to (if-else) -> (if-else) -> if.
Good explanation, Mike. For braces, I strongly agree with you that curly braces be used after every while, do/while, if-else, for, and for-each structure, even if there is only one statement. Actually, according to coding guidelines from lots of companies, curly braces are required at all times. Except for taking the certification exam, always using curly braces would be a good idea as well as good practice, in my opinion.

For my original post, the fact is Java also accepts structures like if -> else if -> else if, instead of the standard if -> else if -> else only. But the "non-standard" structure should be avoided while writing code, I guess? Since nearly every programming textbook would teach you only the "standard" structure.
We all know the standard if-else structure is like if -> else if -> else:



But I do have seen some codes without the ending else:



Seems it is actually equivalent to the three parallel if statements:



So is the no-ending-else structure is a bad coding practice? Does it matter to compilation speed since Java does not find the ending else?
Good explanation, Paul. But the point is if test takers encounter two options in the actually exam that are opposed to each other, like the example above, which one should they choose?

Say, one option claims that "an instance variable of type float defaults to 0.0f", while the other one claims that "an instance variable of type float defaults to 0.0", definitely the former one is the correct answer.

But if one option claims that "an instance variable of type float defaults to 0", while the other one claims that "an instance variable of type float defaults to 0.0", then the latter one should be the correct answer.

But if there is another option "neither is correct", should test takers choose this one instead of the option claiming "an instance variable of type float defaults to 0.0"? Interesting.

A recap for new learners regarding to assignment for double and float variables.

Thanks for your reply, Campbell. But for the review question immediately following Question #6, something interesting happens.

7. Which of the following are correct? (Choose all that apply.)
A. A local variable of type boolean defaults to null.
B. A local variable of type float defaults to 0.0f.
C. A local variable of type double defaults to 0.
D. A local variable of type Object defaults to null.
E. A local variable of type boolean defaults to false.
F. A local variable of type float defaults to 0.0.
G. None of the above



Local variables do not get assigned default values, so the correct answer is Option G (tricky!). But the explanation gives another scenario:

If this question were about instance variables, options B, D, and E would be correct. A boolean primitive defaults to false, and a float primitive defaults to 0.0f.



Since Option B is correct, Option F is incorrect, as the two options are opposed to each other.

So in my opinion, strictly speaking, an instance variable or class variable of type float defaults to 0.0f and prints to 0.0. The same is true for type double.