Remove usage of Guave

[vogella]

IIRC I saw recently a discussion from @akurtakov that the usage of Guave in lsp4e would be desired. Opening this issue to capture this.

@ptziegler does the same at the moment for WindowBuilder see for example eclipse-windowbuilder/windowbuilder#615

[vogella]

Is it actually used? https://github.com/search?q=repo%3Aeclipse%2Flsp4e+guava&type=code does not show any usage in Java files.

[akurtakov]

Guava is not in the packagename. You should search for com.google.common .

[vogella]

Still only 8 usages. Maybe @ptziegler can help here also after his experience with wb?

[ptziegler]

From what I can tell, only the following part of Guava is used is lsp4e:

• Chars.contains(<Char Array>, <Char>)
• Functions.identity()
• Strings.nullToEmpty(<String>), Strings.isNullOrEmpty(<String>)
• ThreadFactoryBuilder
• Ranges & RangeMap

If necessary, the first four could probably be rewritten to not use Guava anymore, but except for Functions.identity() (which should be identical to java.util.function.Function.identity()), I don't think there is a drop-in replacement.

The usage of ranges pretty much requires Guava (or a library with similar functionality). Whether a migration is worth not carrying a 2MB dependency around, I can't answer.
The reason I work on this for WindowBuilder is primarily because:

• we still use e.g. the Guava Predicates, which have also been introduced with Java 8
• we use both Guava and Apache Commons to do basically the same thing (create & manage collections)

Both reason don't seem to apply here.

[sebthom]

We are using guava in tm4e (CacheBuilder, GsonBuilder, Iterators, Strings, Lists) which is usually used together with lsp4e. I don't see us removing it from tm4e without introducing other new dependencies. So I don't really see the benefit of removing it from lsp4e.

[laeubi]

We are using guava in tm4e (CacheBuilder, GsonBuilder, Iterators, Strings, Lists) which is usually used together with lsp4e.

See

• Consider migrating away from guava library (or make its use internal) eclipse-tm4e/tm4e#607

by the way m2e uses guava as well for the sake of CacheBuilder it might be good to extract that part into a separate artifact or have an Eclipse plain vanilla replacement for that.

[laeubi]

Also see

• Add LSP supporting libraries eclipse-platform/eclipse.platform.releng.aggregator#1476

for a discussion where the usage of guava currently prevents usage of LSP4e in eclipse-platform while it seems a technology that should be used even more there and currently requires several plugins to ship their own what can then create even more problems of competing versions.

[HannesWell]

by the way m2e uses guava as well for the sake of CacheBuilder it might be good to extract that part into a separate artifact or have an Eclipse plain vanilla replacement for that.

That's right but I think this can be reworked to use a LinkedHashMap instead.
In fact it was already changed to use only a LinkedHashMap, but the change was reverted because there were regressions. But this was just a quick solution and with more testing it could probably have been solved without Guava.

And if only a more complex cache is necessary than can reasonably be implemented based on standard java, the caffeine library might be worth a consideration. It is similar to guava's caches but much smaller.

[laeubi]

The problem with maps is that these are not reentrant safe and that was the problem with LinkedHashMap as far as I remember. One can usually solve this with one indirection class, nevertheless it was just an example that often one does not really need "guava" but only a small portion of it :-)

[laeubi]

We are using guava in tm4e (CacheBuilder, GsonBuilder, Iterators, Strings, Lists) which is usually used together with lsp4e.

But it is not a requirement to use tm4e so I still thing it would be beneficial especially as tm4e now has removed guava dependency:

• Consider migrating away from guava library (or make its use internal) eclipse-tm4e/tm4e#607

[vogella]

I don't see us removing it from tm4e without introducing other new dependencies.

That was a fast turnaround. Thanks @sebthom for the removal of Guava in tm4e.

[sebthom]

@vogella I thought that Gson is part of guava, but that is not the case. so removing guava was not as complicated as anticipated.