a hasver wrote:page 929 (CERTIFICATION SUMMARY JDBC)
"...added to the Connection object (the Connection.createConnection(int,int) method...." should be Connection.createStatement(int,int)
J Deckarm wrote:chapter 12, self-test 8
code line numbers seem to be irrelevant here, no response uses them
Don Fredricks wrote:The Two-Minute Drill at the end of Chapter 6 (page 361) contains the following statement:
"The default block can be located anywhere in the switch block, so if no preceding case matches, the default block will be entered, ..."
I suggest that the word "preceding" is not quite correct; if no other case matches, the default block will be entered.
Henno Vermeulen wrote:OCA Mock Exam Question 41.
According to the answers, the statement "Encapsulation makes it easier to reuse classes" should be true.
I think this is not immediately obvious and is debatable, so I would lean to not true.
Jefferson Madalena wrote:on chapter 3, page 175, in exam watch notes
To be:
int j, k=m+3, l, m=1; // illegal: m is not declared and initialized before k uses it
Henno Vermeulen wrote:The diagram on page 494 claims that the (java.nio.file.)Files class uses the Paths class. This is not correct. It uses the Path interface!
Henno Vermeulen wrote:On page 504 they say about this:
So Java actually does not give nonsense but does the only right thing to do here. For all it knows the Path referred to by "Model.pdf" may be a directory and the Path referred to by "dir" may be a file!
C Selberg wrote:Chapter 10 page 552
Correct:
If getInstance() weren't public, we would still have a singleton. However, it wouldn't be as useful because only static methods of the package would be able to use the singleton.
J Deckarm wrote:chapter 8, page 458
We can call getObject() to get a non-String value:
Locale locale = new Locale(args[0], "CA");
=> args[0] doesn't seem to make much sense here, from the example context it should be likely "en" instead
J Deckarm wrote:Chapter 9, page 521
In the "tricky example", creation of paths 1,2 and 4 fails with "java.nio.file.InvalidPathException: Illegal char <*> at index..." on Windows. Works correctly on Unix
J Deckarm wrote:Chapter11, page 611-612
If the collection/array you want to search was sorted using a Comparator, it must be searched using the same Comparator, which is passed as the second argument to the binarySearch() method
=> It seems to be actually the third argument: static <T> int binarySearch(T[] a, T key, Comparator<? super T> c)
J Deckarm wrote:Chapter 11, page 618
"which produces something like this:
Dog@1c
..."
=> since we are getting the Dog instance with the name "aiko" here, and the hashcode is name.length(), this output seems to be Dog@4
J Deckarm wrote:Chapter 11, page 581
"You must also be able to recognize an appropriate or correct implementation of hashCode(). This does not mean legal and does not even mean efficient."
Roger Jenkins wrote:Chapter 3, page 175, on the last line of the Exam Watch:
It says that the following is not legal:
int x, y=x+1, z; // illegal: x is not initialized before y uses it
J Deckarm wrote:chapter 14, page 804
Here is a demonstration of queue add/remove methods using a LinkedTransferQueue object tq. But LinkedTransferQueue itself is unbounded, so "if bounded", "if full" etc. comments beside tq.add(), tq.put() etc methods seem to be confusing
J Deckarm wrote:chapter 15, page 901
public String getMessage() states: "But this method returns the detailed reason why the exception was thrown. Note that this is not the same message that is returned from the toString() method, i.e., the method called when you put the exception object instance into a System.out.println method"
=> for me the only difference seems to be that the exc.toString() printout starts with "java.sql.SQLException: ", but then the error text itself is the same as that of exc.getMessage()
J Deckarm wrote:chapter 15, page 905
"A resource declared in the try-with-resource statement must implement the AutoCloseable interface. ...Connection, Statement, and ResultSet all implement the AutoCloseable interface"
=> Two remarks on this
(1) As much as I know it is also OK if the resource implements the Closeable interface which extends AutoCloseable
J Deckarm wrote:(2) Connection, Statement, and ResultSet are interfaces themselves therefore they seem to be in fact extending the AutoCloseable interface