Reduce usage of Guava

[HannesWell]

Guava is a dependency that's often difficult to handle (one reason is that Xtext is re-exporting it) and many of the enhancements Guava offered are part of the Java's standard library in recent versions. For the most commonly used elements in Guava there are often (almost) drop-in replacements or equivalent alternatives that are simple to migrate to. Many elements in Guava even recommend to use standard alternatives in their doc.
Therefore I want to suggest to replace Guava where it is possible.

In general the usage is split into two parts:

• Internal usages, which can be replaced by a technical suitable solution at any time.
• Usage in APIs.
  For APIs alternatives would have to be added and the existing methods would need to be deprecated for some time before they can be removed? This also relates to Xtext and (binary) backwards compatibility #2668 and should probably be handled together.

In general Guava is heavily used by Xtext, searching the *.java files in this repo for com.google.common gives 3535 hits. So replacing it is a major task and probably more a journey. At its end maybe Guava can even be dropped completely.
But since it is hard to even get just a completely overview of its usage, my suggestion is to start with simple cases like replacing Lists.newArrayList() by new ArrayList<>() etc. only in internal usages and see how far we can get.

[szarnekow]

Before putting more effort into this, let's analyze the impact of such a change and agree it's worthwhile to pursue.

Can we agree on a few things:

• Backwards compatibility is an asset - both source and binary compatibility
• Disruption for users without any benefit from the users' perspective is counter-productive
• Guava is a mature library with a ton of useful APIs, some (not all) of which have nowadays and equivalent in Java
• Mistakes were made in the past (most severe is probably the habbit of re-exporting dependencies)

What is the net-effect of overloading existing APIs with java.util.function types where currently Guava's pseudo-deprecated types are used? Likely warnings in source code. Is it any better for an existing code-base? I've doubts.

Before we follow through and look at the detailled implications of whatever change we're going to make, I'd like to understand why it is better. Better beyond an academic perception of better. I want to see that the disruption is carrying its own weight.

Of course this is only my opinion, so others are clearly invited to share their thoughts, too. But before more time is (maybe wasted, maybe not) on code changes, let's agree on a goal and let's make a plan that'll lead to that goal.

[LorenzoBettini]

In general, I'd have no problem replacing things like Lists.newArrayList() with new ArrayList<>(), and that's what I've already done and doing when changing existing code.

I have doubts (see #2978 (comment)) that having overloaded methods with functional interfaces would work: the Java compiler would issue an error if you pass a lambda expression, wouldn't it?
In fact, I see explicit casts in @HannesWell 's PR when passing lambda expressions to the new method from the deprecated one. If Java issued compilation errors, that would be a huge problem ;)

If switching to Java functional interfaces instead of the Guava ones is considered, I think it would be better to simply replace the functional interfaces from Guava with the ones of Java without deprecation and overloading. That would be API breakage, but it should go completely unnoticed if clients used to call such methods with lambda expressions. I don't know if it could give problems from a binary point of view, though.

[szarnekow]

I don't know if it could give problems from a binary point of view, though.

That would indeed be source-compatible but not binary-compatible.