-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider migrating away from guava library (or make its use internal) #2838
Comments
lol with 0 contributions this will happen in 2033 |
I see some recent (open) contributions here so it is not completely hopeless: :-) |
Bug fixes and small features are happening |
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). |
The breaking is us using guava in api methods |
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. |
You closed it as completed ;-)
This does not mean you have to require Guava... as mentioned above
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... |
By the way the
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. |
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. |
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. |
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:
See
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
where the use of guava in xtend affect lsp4j
The text was updated successfully, but these errors were encountered: