Remove guava and use java8 constructs (#1082)

[copa2]

This PR removes the guava library dependency with java 8 constructs.
(Fix issue #1082)

The main reason is that other code also uses guava in a incompatible version and guava is not always binary compatible.

Incompatiblilites:

• This will update jdk from 1.6 to 1.8 as minimum version
• Binary incompatiblities
• Public API changes where guava constructs have been exposed

What is missing:

• Cleanups (Predicates, Function can be written more compact with java 8)

Checked alternatives:
Using shading plugin to shade guava. This makes each sub-project artifact big due whole guava library has to be shaded into the artifact.

NOTE: This PR replaces previous PR #2082 due unneeded changes regarding crlf.

[copa2]

Well this is the behavior like it was before with Guava check.

[copa2]

I will remove the Equivalence class when this is merged. I think normal wrappers for these use cases are ok. I keep it as similiar as before so that merging from upstream is simpler.

[copa2]

Hi dilipkrish

Just checked the failure I receive from circleci.
Problem is that the CachingOperationReader already today is probably not doing what is expected.

springfox/springfox-spring-web/src/main/java/springfox/documentation/spring/web/scanners/CachingOperationReader.java

Line 57 in ec9af57

return cache.getUnchecked(new OperationCachingEquivalence().wrap(outerContext));

Each entry receives a new OperationCachingEquivalence which calls the Wrapper.
Within the Wrapper the equals checks if the Equivalence is the same Object
if (this.equivalence.equals(that.equivalence)) { before it calls doEquivalent. So all entries will never be equal an no caching will take place today.

Normally you only create one Equivalence object and then call wrap on the same. If I change the code on master like this I will get the same failure.

To fix it properly we should probably reconsider what is equivalent for the Operation. Currently it fails in the PetStoreResource for getPetInTx and getPetInCA. It is looked equivalent, as the key data is the same. Probably we have additionally to check the static params or use the methodName. What do you think?

@dilipkrish
I looked into the swagger specification regarding path and operations (https://swagger.io/docs/specification/2-0/paths-and-operations/). Under "Query String in Paths":

Query string parameters must not be included in paths. They should be defined as query parameters instead.

So in my opinion the test FunctionContractSpec.should honor swagger v2 resource listing petstoreTemplated is wrong. There should not exists 2 paths (/api/store/search?x=CA,/api/store/search?x=TX). There should only exist one (/api/store/search). In my opinion the QueryStringUriTemplateDecorator should not exist as it adds the "x=CA" to the path.

Or is there some other reason I don't understand?

[dilipkrish]

@copa2 thank you for the PR! I've pulled in the PR to remove guava dependency

[rxxy]

QueryStringUriTemplateDecorator

@dilipkrish I looked into the swagger specification regarding path and operations (https://swagger.io/docs/specification/2-0/paths-and-operations/). Under "Query String in Paths":

Query string parameters must not be included in paths. They should be defined as query parameters instead.

So in my opinion the test FunctionContractSpec.should honor swagger v2 resource listing petstoreTemplated is wrong. There should not exists 2 paths (/api/store/search?x=CA,/api/store/search?x=TX). There should only exist one (/api/store/search). In my opinion the QueryStringUriTemplateDecorator should not exist as it adds the "x=CA" to the path.

Or is there some other reason I don't understand?

Has this problem been solved?