More generics in Dataverse and SAVFileReader classes

[bencomp]

Related to #775 - Eclipse found a few instantiations of ArrayLists without types. Builds on my machine :)

[landreev]

Re: SAVFileReader.java - that one is on my list of classes to fully rework and clean up.
These changes, with generic ArrayList instantiations, definitely look ok; as in, they should not hurt...
But, a stupid question perhaps - is this really necessary?
It's interesting that, apparently, Eclipse and Netbeans seem to have different standards of what should be considered "clean" code.
Not only is Netbeans NOT complaining about the lines above; it actually complains whenever I do something like

        List<SummaryStatistic> testlist = new ArrayList<SummaryStatistic>();

• it shows a hint implying that the type declaration is "redundant".
  I'm definitely willing to make any changes that would make our code cleaner and more standard; just a little confused as to what the rules are.

[bencomp]

Interesting indeed. I didn't know the answer to what the 'correct' way is - I still don't know what is best, let alone that I should tell you what to do :) (@pdurbin suggested code style checker plugins for Jenkins in #775)

According to someone on StackOverflow, there is a reason for Java 7's diamond operator (e.g. ArrayList<>()) when you could also use the raw type (ArrayList()): it enforces checking of correct application of generic typing. I think that to have the same strictness in Java 5 or 6 you do need the fully typed type.

Not to be pedantic or annoying, but What is a raw type and why shouldn't we use it? gives a nice overview of reasons to not use raw types.

[pdurbin]

I always let NetBeans insert the diamond operator since we are requiring Java 7 or higher.

[bencomp]

Let me create a different smaller pull request, as I discussed with @pdurbin on IRC. I now used NetBeans to refactor the full type arguments into diamonds (e.g. = new ArrayList<String>(); -> = new ArrayList<>();).