Better Java

Using public fields could be a bad idea if on classes that are exposed to third parties because it prevents you from changing it to a calculated field while keeping compatibility. However, this is going to be a very small number of classes.

Personally I have a small Tuple class I use for small immutable data holder objects that automatically implements hashCode and equals:

    public final class DataHolder extends Tuple2<String, Integer> {
        public DataHolder(String data, Integer value) {
            super(data, value);
        }

        public String data() { return get(0); }
        public Integer value() { return get(1); }
    }

Obviously there's a bunch of limitations: you can't use primitive data types, and it doesn't really scale past 3 or 4 fields, and can get hairy when you have multiple fields of the same type. It's easy to graduate once you get to that point though.

I disagree on Util classes. They're fine so long as they're as well-tested as regular code and divided up by the libraries they depend on. (Put all your IO utils in one place, all your database utils in another, and so on.) Guava has lots of nice utility methods for Maps, Lists, streams, and so on.

Mostly good advice. I'm surprised he talked about Joda Time and Java 8 without mentioning Joda Time is (essentially) included in Java 8.