Why Elastic Search Is Removing Google Guava

Especially if they want to keep parts like Splitter and Joiner and just copy them over. I just ran into too many libraries that copied Guava into their own namespace and now your project depends on x different copies of Guava indirectly. Besides that I find it strange to get rid of ImmutableList as I don't see any usable alternative. I also find the newXXX methods very helpful and much more readable (e.g. Maps#newHashMapWithExpectedSize) and preferable over constructor usage even with the diamond operator as it also allows you to change the implementation afterwards.

Re: Why Elastic Search Is Removing Google Guava

#6

Post by Randgalt » Mon, Sep 07, 2015, 6:35 AM UTC

sam_lowry_ wrote: post #2

Where is the why?

It's there about 10 comments down or so

Re: Why Elastic Search Is Removing Google Guava

#7

Post by Randgalt » Mon, Sep 07, 2015, 6:35 AM UTC

sam_lowry_ wrote: post #2

Where is the why?

This should not be taken as a judgement on Guava. Guava is a popular library, and for good reasons. But the rationale here is rather simple:

A lot of the benefits of Guava have been supplanted by additions to the JDK in JDK 7 and JDK 8 (e.g., the diamond operator, lambdas, and streams). We are no longer shading dependencies in the Elasticsearch jar (see #13252). We do not have a proper Java client today; this means that developers that depend on the Elasticsearch jar are likely going to have to deal with Guava version conflicts (which are likely since Guava is popular). Developers do embed Elasticsearch inside web containers which creates conflicts with the provided versions of Guava. Plugin developers encounter issues with Guava version conflicts (again, because Guava is popular). All else equal, fewer dependencies is a positive. In short, the internal benefits have been reduced, and there are external benefits to developers to removing Guava.