Reduce usage of Guava

[HannesWell]

Guava is a great library that brought many great new features into the Java world. But many of them are now part of the Java standard library, either directly or indirectly through other new features. When using Java-11 or later, many of the conveniences provided by Guava can be replaced with standard Java with the same level of convenience.
At the same time Guava can be a difficult dependency in the OSGi world (like Eclipse) because of its frequent major versions and because it is often reexported.
In unfortunate situations this can prevent updates of other dependencies of an application.

Therefore I want to propose to reduce the usage of Guava, eventually it might even be possible to drop Guava entirely.
If you are interested I can provide corresponding PRs to replace uses Guava step by step, where possible.

[HannesWell]

One question regarding compatibility: It looks like KLighD uses Guava's Predicate and Function type in some of its APIs. Since Java-1.8 they have a (almost) drop-in replacement in the java.util.function package and can be replaced easily.
But I assume you want to keep these Methods and fields referencing them first and only make them deprecated and only remove them in the next major version, don't you?

[NiklasRentzCAU]

If we are to remove Guava, KLighD will deprecate the current API first, eventually removing it probably during a major version update. I try to keep semantic versioning a thing, especially for the APIs for using KLighD outside of Eclipse.

[HannesWell]

That's reasonable.

I have looked further into this topic and I think the main work will be reworking the 'Iterables'-Pipelines to Stream-Pipelines, then replacing some Multimaps and Guava's Predicate and Function. Most of the latter is trivial if their implementations are converted to lambdas and in general most of that seems doable (even with Java-1.8),

What could be a bit difficult is replacing some advanced Set-Diff views, but I think even that can be achieved in the end. It will probably just be that for that particular use case the code using only standard Java might become a bit longer than before.