New developer jar libraries - guava, hamcrest-all, mockito

[DanVanAtta]

The following three libraries I think will need to be added very soon:

• guava
• mockito
• hamcrest-all (contains additional hamcrest matchers)

Down the road I think we'll be adding the jars for:

• dagger2
• spock (?)

And of course eventually maven/gradle will be getting this stuff for us, so we won't have the jar file checked in. Till then, wanted to raise this issue, see if there was any objection.

[veqryn]

What specific functionality do each of these make possible?

[DanVanAtta]

guava - google's version of apache commons. Contains a dozen one-liner utilities, immutable collections, lots of useful stuff.

mockito - mocking library, triplatest had a discussion about alternatives. Seems like nobody minds too much and wished me a lot of luck to use mocks at all in this code

hamcrest-all - adds additional hamcrest matchers, makes hamcrest unit assertions useful (the matchers are pretty key to hamcrest)

dagger2 - dependency injection. Spring but lighter weight, smaller scope, and no XML

spock - behavioral testing library

[veqryn]

mockito, hamcrest, and spock, would not make it into our production releases because they are only for testing, correct?

[DanVanAtta]

Assuming we bundle things well, correct. To boot, dagger and spock will be a bit more time and discussion before they are added in. Guava, mockito and hamcrest I would expect to be added in pretty soon. Major points are probably more if those are the right libraries. Moving from Junit3 to Junit4+Hamcrest+Mockito are not terribly controversial as far as library picks. Some people I know really hate guava, but guava is very useful and generally a person should either be using guava or apache commons, or both : )

[veqryn]

Do any of these libraries require a certain version of java (7/8)? Would you still use guava if we upgraded to java 8? I'm fine with junit4/hamcrest/mockito.

[DanVanAtta]

In short, no version of java required. Going to java 8 I would still keep guava around for certain.

Longer answer: That library stack is effectively what I had at my last employer (couple months ago), so I've experience with them running with Java 6. So they can run in Java 6 with a version that will give us what we want (mostly the API).

Guava is an interesting one, and yes it would still be used going to java 8. It has some features that try to replicate Java 7 but in Java 6. For example: List myList = Lists.newArrayList(); (guava) Compare that to: List myList = new ArrayList<>(); (java 7) vs: List myList = new ArrayList<String>(); (pre java7)

The three examples show three different degrees of coupling, the top is the least coupled to the types "List" and the type "String" and the bottom is the most coupled.

The guava version is arguably better than Java7 in some respects since you don't invoke new. A colleague of mine once said that guava helps you actually stay on Java 6 because it takes some of the benefit of java 7 away.

If you are not familiar with guava, I very much recommend this: https://code.google.com/p/guava-libraries/wiki/GuavaExplained The above link describes a lot of features and even reasoning behind guava. A lot of it are useful day-to-day one liner type of things (these types of tool I regard as very important for being productive)

[DanVanAtta]

Closing, sounds like if we have some new Jars appear there won't be any surprise. Hamcrest and mockito likely will be very soon, guava same time or shortly later I would expect, and Dagger and Spock are more down the road type of items for the moment.