[jcommon] fix MixTypedMap's type checking

Summary: the super in the class wasn't what we wanted--the class is fixed, but we wanted the *instance* to extend the class type. This allows safe writing and casting on reads.

Test Plan: 1. mvn clean test (includes tests for this data structure)

Reviewers: wwang, groys, timw, johnclyde

Reviewed By: johnclyde

CC: puma-dev@lists

Differential Revision: https://phabricator.fb.com/D588499
[jcommon] with MixedTypeMap, switch to using guava TypeToken internally

Summary:
Using this allows reified generics such as List<String> as "types".
The change is backwards compatible as far as the API

Test Plan:
1. existing unit tests
2. added more tests reified cases and Class vs TypeToken apis

Reviewers: timw, groys, dain

Reviewed By: timw

CC: puma-dev@lists, jcommon@, erling

Differential Revision: https://phabricator.fb.com/D591205
[jcommon] Remove accidentally-committed log4j.properties

Summary: A non-test log4j.properties was accidentally committed

Test Plan: `mvn -U clean test`

Reviewers: srash

Reviewed By: srash

Differential Revision: https://phabricator.fb.com/D592580
[jcommon] Array and LongArray

Summary:
1. introduce a simplified "list" or in this case, Array interface.  It's generic so that it can be used in classes that want to be generic, but allows for primitive-backed implementations

2. reference implementation of Array for Long.  There are data structures already implemented on long[] that if changed to use Array, can be changed to generic and then implementing Array for the type (one can use AbstractList possibly easier). Examples are the LongHashSet and a "heap" implementation for CTA that does 'flat' long-tuples.  Could be generified to any primtiive tuple

I made this thread-safe, mostly by synchronizing the methods.  Even the iterator *should* be thread-safe, but definitely does not throw CME.  it makes a best-effort to give as much valid data as it can.  It will not throw CME or give invalid data.  It's contract is similar to ConcurrentHashMap in that you are seeing a series of values from the list that were in it at sometime.

Ideal use of the iterator is NOT in a concurrent case, though, with some locking done to ensure this.

Thought: we could provide a SynchronizedSimpleArray that worked same as Collections.synchronizedX since SimpleArray doesn't specify thread-safety.

Test Plan:
1. existing tests
2. new unit tests for reference impl

Reviewers: timw, dain, martint, nitayj

Reviewed By: nitayj

CC: jcommon@, dphillips

Differential Revision: https://phabricator.fb.com/D506752
[jcommon] Make TimeInterval.getType() public

Summary: - Need to expose it to implement PQL rendering in puma

Test Plan: - unit tests

Reviewers: timw, srash, groys, wwang

Reviewed By: timw

CC: jcommon@

Differential Revision: https://phabricator.fb.com/D604653
[jcommon] refresh dependencies

Summary:
1.guava -> 13.0.1
2. #1 required explicit dependency on

    <dependency>
      <groupId>com.google.code.findbugs</groupId>
      <artifactId>jsr305</artifactId>
      <version>2.0.1</version>
    </dependency>

for implementations of annotations for software defect detection ( http://code.google.com/p/jsr-305/)

3. jackson latest updates

4. other misc updates

Test Plan: mvn clean test

Reviewers: timw, martint, cgthayer

Reviewed By: cgthayer

CC: jcommon@

Differential Revision: https://phabricator.fb.com/D593999
[jcommon] fix cobertura with java7

Summary:
roll back to 2.8.1 for surefire and add config option for JVM (see diff)

Test Plan: mvn clean cobertura:cobertura

Reviewers: timw

Reviewed By: timw

CC: jcommon@

Differential Revision: https://phabricator.fb.com/D607389
[jcommon] Allow config to be pulled from a customized location (rather than only from files)

Summary:
Puma uses ConfigProviderImpl to parse config information, which uses a filed based parser ExpandedConfFileJSONProvider. Ideally we would like to support the config to be pulled from other locations (for example from a metastore). This is  to generalize ConfigProvderImpl to take a "ConfigResolver". The implementation is backward compatible.

Many thanks to Tim for providing feed back! I like the new way a lot more. :-)

Test Plan: mvn test

Reviewers: srash, timw, ajaiswal, ehwang

Reviewed By: timw

CC: security-diffs@lists

Differential Revision: https://phabricator.fb.com/D599175

Task ID: 1795673
use json 1.0.0 (internal)
[maven-release-plugin] prepare release jcommon-root-0.1.2
Merge tag 'jcommon-root-0.1.2' into HEAD

[maven-release-plugin]  copy for tag jcommon-root-0.1.2