Errata

The fact that 'wc -l somefile.txt' returns 1025 does not mean that there are 1025 lines in the file (header + 1024 lines of data). The output of 'wc' depends on the file format: if the last line ends with newline character (as it often happens and sometimes even considered to be a good practice), the output will be one more than the number of lines in the file.

Catching generic Exception is a very bad practice, actually, famous anti-pattern in Java. The code should catch IOException thrown by readLine, or do nothing at all.

The book states:
"Any methods acting on Record could be static methods ideally in their own class titled something like RecordUtils."

This is a very strange idea. Java is object-oriented language, and encapsulation is one of the important principles of object-oriented design. Encapsulation tells us that the data should be bundled with methods.

Please refer, for example, to the article in Java World (http://www.javaworld.com/article/2075271/core-java/encapsulation-is-not-information-hiding.html) where the author shows an example of having the data in Position class and methods in PositionUtility class, and proceeds with explaining why it's not the way things should be designed. To quote the article: "Though the code may use Java objects, it does so in a manner reminiscent of a by-gone era: utility functions operating on data structures. Welcome to 1972! "

If the first br.readLine() throws IOException, the catch block will try to print out 'line' which is not yet defined; instead it should print 'header'.

"It is straight forward to build our dataset now using org.simple.json" -- what is "org.simple.json"? Google doesn't find anything like that. I suspect the author means JSON.simple (https://code.google.com/p/json-simple/)

Related code example has the following major problems:

1. If indeed the author means to use JSON.simple, the first two import lines are wrong. They should be:

import org.json.simple.JSONObject;
import org.json.simple.parser.JSONParser;

(notice the order of json and simple, and "parser" before JSONParser)

2. The code won't compile in any case, because it defines JSONObject called 'obj' but tries to use something undefined called 'j'.

The book says: "Note that successively using string += string_part calls the StringBuilder class, so you might as well use StringBuilder anyway (or not). "

Using something like "string += string_part" in a loop is a mistake. The string concatenation indeed uses StringBuilder class, *creating and destroying new instance of StringBuilder in each iteration of the loop*, which may create quite a lot of overhead.

When building string from parts in a loop, one always must use StringBuilder.

Instead of doing

bw.write(s + "\n");

one should do

bw.write(s);
bw.newLine();

Please refer to the documentation for BufferedWriter class for details.

I think on Mac no amount of "ls -alh"ing would find the proper directory. The way to run ij on Mac could be:

$ $(/usr/libexec/java_home)/db/bin/ij

java_home finds the right directory, something like /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home

Following the symlinks from /usr/bin/javac will lead to /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javac instead, and it seems there's no ij nearby.

While ij can seemingly be run with given java command line (java -cp .../derbytools.jar org.apache.derby.tools.ij) it's a very bad idea, at least on Mac.

Compare:

(Proper way to run ij)

$ $(/usr/libexec/java_home)/db/bin/ij
ij version 10.11
ij> connect 'jdbc:derby:memory:MyDbTest;create=true';
ij>

(calling it with given command line)

$ java -cp /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/db/lib/derbytools.jar org.apache.derby.tools.ij
ij version 10.11
ij> connect 'jdbc:derby:memory:MyDbTest;create=true';
ERROR 08001: No suitable driver found for jdbc:derby:memory:MyDbTest;create=true
ij>

The 'ij' script seem to do much more than just add derbytools.jar to classpath.