Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[viatra-dev] Guava usage reduction: status report and questions 
Hi all,

as we have discussed before, for version 2.0 we want to reduce our usage of Guava. Our original plan was the following:

 * Guava classes _must not_ be present on any API
 * Guava classes _should not_ be used in the query and transformation runtime code.
 * There is no need to reduce Guava usage in code that depends on Xtext as Xtext (and also Xtend.lib) already brings in that dependency.

I tried to reduce our usage of Guava in the query and transformation runtime projects, and have already pushed in (quite) a few commits that remove most uses of Guava (mostly from org.eclipse.viatra.query.runtime* and org.eclipse.viatra.transformation* projects). These changes were aimed to completely remove Guava dependencies in runtime (not only from the API), but I have found a few problematic cases. I have created an API usage report [1] that lists at all the remaining usage of Guava. The most important issues here:

 * There are a few utility methods that calculates the union, difference, powerset etc. of sets without creating new set instances. These methods can be replaced on a case-by-case basis with appropriate stream/iterator usage, but it is non-trivial. Typical usage:
   * The LS planner relies on quite a few of these.
   * Analysis utilities such as the flattener or functional dependency calculator also uses these.
 * We had quite a few uses additional collections, such as Multimaps, Multisets (bags) and Tables. These are problematic to replace as there is no alternative for them in Java.
   * Multimaps and Multisets are used basically in every major component.
   * Furthermore, in a few cases multimaps and multisets are visible in the API, e.g. in case of the QueryResultMultimap or the LocalSearchBackend classes.
   * EVM uses Tables internally to store the rule activations.
   * The Base index uses Tables internally (I am not 100% sure, but if the gerrit change [2] is finished, this issue should be fixed).

Alternatives for the Multimaps, Multisets and Table usage:

  A. We replace them with basic Java collections (e.g. set of sets). This is error-prone, and will require a lot of effort, as we have quite a few cases where these collection types fit naturally.
  B. We replace all Guava collection usage with the appropriate collections from Eclipse Collections. While much easier to go this way, it still is not free, as Eclipse Collections have a very different API style than the one we are accustomed to; and we are replacing one dependency with another.
  C. We keep Guava usages, except where it is visible on the API; there we replace it with basic Java collections. This should be the smallest effort to do, but (1) we have to be very careful not to keep (for now) or reintroduce (in the future) Guava classes on the API (and there is very limited tool support with this).

Alternatives for the collection utility classes:

  A. Replace them with similar methods from Eclipse Collections.
  B. Reimplement them in plain Java.
  C. Keep them; they are not visible in the API.

What do you think, what direction should we go further?

Best regards,
Zoltán

 [1] https://drive.google.com/open?id=1RS0qV7X-pPjep-xWQVty7bzcJxGNg2Fu
 [2] https://git.eclipse.org/r/#/c/106423/
-- Zoltán Ujhelyi

Eclipse Technologies Expert
IncQueryLabs Ltd.

Back to the top