replace usage of guava with standard java

[askoog]

Avoid adding extra third party dependency 'guava' by replacing methods with equivalent alternatives in standard jdk.

This helps users of etcd since every transitive third party dependency requires more code to be downloaded and might result in dependency conflicts.

fixes #1207

[liangyuanpeng]

make sense for me

[lburgazzoli]

@askoog does this actually remove guava dependency ? I think this is still something that is transitively provided by grpc-java

[liangyuanpeng]

I agree with reducing direct dependencies even though indirect dependencies may exist.

[lburgazzoli]

the reason guava dependency is explicitly declared was to control it as unfortunately there were cases where guava was clashing anyway, but we can remove it and see how it goes.

Unfortunately it does not prevent to break apps using jetcd as a library.

[lburgazzoli]

@askoog @liangyuanpeng I'm not very convinced by removing the explicit dependency as guava is anyway leveraged by jetcd so it is a good practice to explicit defines dependencies the application depends on instead of rely on transitive dependencies as any change in the transitive dependency chain can break the app.

So I'm fine to replace guava with standard java code but not to remove the dependency as long as jetcd still requires it.

WDYT ?

[askoog]

wow, you guys are fast! Thanks for the quick response!

You are right @lburgazzoli, this does not actually remove the dependency since it's also transitively included. And I agree with you that you should declare the versions of your used transitive dependencies as well.

The problem we were trying to solve initially was that in some of our legacy applications we were bound to guava 20 which grpc seems to work fine with, but the usage of the Streams class in jetcd was not compatible with such an old version. So by removing the usage of guava code directly but keeping the specified dependency version will work for us. I will revert the changes in the libs file so that the version is still specified there

[lburgazzoli]

if you find out other guava bits that can be replaced by any standard java class, I'm more than happy.

In fact one of the reason we have some additional wrappers was exactly to avoid exposing guava as much as possible at well, that is a pain :)

[lburgazzoli]

I don't see any build file with libs.guava as dependency, I think the modules where guava is required should explicit declare the guava dependency

[lburgazzoli]

@askoog any update ?

[lburgazzoli]

@askoog can you please rebase / fix conflicts ?