Consider migrating away from guava library (or make its use internal)

[laeubi]

Google Guava is a collection of useful things but there also lies its weakness as this results in big size, and heavy dependencies on specific versions even if not all parts are affected. Also with today modern java many things can be archived with plain java as well.

As it is know to create dependency-hell problems, I'd like to suggest to:

• replace all usages where possible with standard java
• embeds the code that can't be replaced easily in an internal package

See

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

for a discussion where the usage of guava currently prevents usage of LSP4J 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.

See also

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

where the use of guava in xtend affect lsp4j

[cdietrich]

lol with 0 contributions this will happen in 2033

[laeubi]

I see some recent (open) contributions here so it is not completely hopeless:

• https://github.com/eclipse/xtext/pulls

:-)

[cdietrich]

Bug fixes and small features are happening
The keep with simrel I do in my spare time
But ditching guava is a gigantic thing also breaking clients

[laeubi]

But ditching guava is a gigantic thing also breaking clients

Client can still include guava for their own convenience and every giant thing starts with small steps (making this visible by an issue is the first one).

[cdietrich]

The breaking is us using guava in api methods

[szarnekow]

I’ll close as won’t fix. We won’t break existing clients. Backwards compatibility is an asset I’m not willing to give up.

[laeubi]

I’ll close as won’t fix.

You closed it as completed ;-)

The breaking is us using guava in api methods

This does not mean you have to require Guava... as mentioned above

embeds the code that can't be replaced easily in an internal package

you could also embed API interfaces and use substitution packages, that way uses that use guava will get them from guava (and xtext as well) but users without guava will get them from the embedded classes from xtext directly.

So I kindly ask to reopen the issue again...

[laeubi]

By the way the

We won’t break existing clients. Backwards compatibility is an asset I’m not willing to give up.

is already intrinsic in xtext/xtend if you rely on external API on your own API the breakage of guava APIs (and that's what people often claim, they break API all the time) will immediately result in breaking your API for all older clients as well.

[szarnekow]

People claim many things. Decisions should be based on facts. Neither does Xtext rely on unstable parts of Guava nor does the Guava team do lighthearted changes. Nowadays I’m more confident with Guava types being used in Xtext API then with Eclipse platform usages.

[szarnekow]

You closed it as completed ;-)

Sorry, I must have missclicked on the phone. I stick to the point though, that we don’t have the intention to break clients. Without a compelling reason, I don’t see why this should be reopened.