Errata for OCP: Oracle Certified Professional Java SE 8 Programmer II - Chapter 9

[T Vergilio]

Page 475

The second example moves the addresses.txt file from the directory user to the directory zoo-new, and it renames it to addresses2.txt.

It doesn't rename the file.

[Jeanne Boyarsky]

Agreed. The code should have said addresses2.txt there. Noted this.

Speaking of notes, feel free to create one thread with all these small findings for a chapter. It makes it easier to process and for people to search for.

[T Vergilio]

No worries, Jeanne, will do. I will put any other Chapter 9 ones I find in here.

Thank you!

[T Vergilio]

This is not necessarily an item of Errata.

I have a few questions about question 16 of Chapter 9's Review Questions (page 501):

1) What if the file had a bunch of commas in it? That's a non-empty file which would output nothing, making option E correct.

2) How about if it was a really large file and File.lines() got interrupted half way through reading it? It does, after all, read lazily. Let's say another application modified the file halfway through the process. Wouldn't it throw an IOException, making option A correct?

The first case is down to interpretation of what an "empty file" means, whereas the second is an edge case which I haven't successfully tested, but I would be grateful if someone could help clarify.

Thank you very much!

[T Vergilio]

Now I do have an issue with question 17 on page 502.

Files.walk() will search the root level and all other levels of the file tree, so options E and F are also possible outcomes of executing the code.

If the only place where there are .java files is inside the /animals/cute directory, for example, then E, F and G are all correct.

[Jeanne Boyarsky]

T Vergilio wrote:1) What if the file had a bunch of commas in it? That's a non-empty file which would output nothing, making option E correct.

True. Not really in the spirit of a non-empty file although factually correct.

T Vergilio wrote:2) How about if it was a really large file and File.lines() got interrupted half way through reading it? It does, after all, read lazily. Let's say another application modified the file halfway through the process. Wouldn't it throw an IOException, making option A correct?

Sure. Or you could run out of memory and get an out of memory error.

It's ok to ask here because this is a book and you are studying. Make sure you don't read into the questions on the exam lest you lose points over an edge case the exam writers didn't think of!

[Jeanne Boyarsky]

T Vergilio wrote:1) What if the file had a bunch of commas in it? That's a non-empty file which would output nothing, making option E correct.

True. Not really in the spirit of a non-empty file although factually correct. I'll note it on our private list as something that could be clearer.

T Vergilio wrote:2) How about if it was a really large file and File.lines() got interrupted half way through reading it? It does, after all, read lazily. Let's say another application modified the file halfway through the process. Wouldn't it throw an IOException, making option A correct?

Sure. Or you could run out of memory and get an out of memory error.

It's ok to ask here because this is a book and you are studying. Make sure you don't read into the questions on the exam lest you lose points over an edge case the exam writers didn't think of!

T Vergilio wrote:Now I do have an issue with question 17 on page 502.

Files.walk() will search the root level and all other levels of the file tree, so options E and F are also possible outcomes of executing the code.

If the only place where there are .java files is inside the /animals/cute directory, for example, then E, F and G are all correct.

You are correct. We should have made it clear we meant the highest level only.

[T Vergilio]

This is just a suggestion. On page 461, Table 9.1 shows NOFOLLOW_LINKS as commonly used with Files.move(). This is confusing because the default behaviour of Files.move() is already that. It moves the symbolic link itself, not the target of the link. Specifying the NOFOLLOW_LINKS option, in this case, is redundant.

[T Vergilio]

And a very small typo: Table 9.1, last row.

Method using it may throw an exception (...)

should be

Methods using it may throw an exception (...)

[T Vergilio]

On page 475,

By default, the move() method will follow links, throw an exception if the file already exists, and not perform an atomic move. These behaviours can be changed by providing the optional values NOFOLLOW_LINKS, REPLACE_EXISTING, or ATOMIC_MOVE, respectively, to the method.

Again, the documentation seems to suggest that Files.move() doesn't follow links by default. From the Files API:

If the file is a symbolic link then the symbolic link itself, not the target of the link, is moved.

source: https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#move-java.nio.file.Path-java.nio.file.Path-java.nio.file.CopyOption...-

And from the Oracle Java tutorials:

This method takes a varargs argument – the following StandardCopyOption enums are supported:

REPLACE_EXISTING – Performs the move even when the target file already exists. If the target is a symbolic link, the symbolic link is replaced but what it points to is not affected.
ATOMIC_MOVE – Performs the move as an atomic file operation. If the file system does not support an atomic move, an exception is thrown. With an ATOMIC_MOVE you can move a file into a directory and be guaranteed that any process watching the directory accesses a complete file.

source: https://docs.oracle.com/javase/tutorial/essential/io/move.html

[T Vergilio]

Another typo at the end of page 475:

If the target of the path is a symbol link,

should be

If the target of the path is a symbolic link,

[Jeanne Boyarsky]

Logged the two typos on the errata page.

I noted the move() thing privately. Scott and I had a lot of discussion about how to handle the options and this was the best we came up with. We will talk about it again with Java 9.

[T Vergilio]

Jeanne Boyarsky wrote:I noted the move() thing privately. Scott and I had a lot of discussion about how to handle the options and this was the best we came up with. We will talk about it again with Java 9.

That's why I didn't really enjoy the NIO topic, it's the murkiest of all the objectives. Look at the Files class, for example: it's gigantic, and a lot of the methods are difficult to test if you only have one operating system available, or if your environment doesn't support symbolic links. Plus there are so many cases that are "implementation dependent", you just have to remember them. Not much fun at all