I knew the risks going in, and I’m not very concerned. Suppose - worst case scenario - that Guava 30 removes RangeSet. The solution would be for us to copy RangeSet and enough dependent classes into Calcite to serve our needs. Our support for Guava 30 would be delayed by a month or two.
Sarg is a powerful abstraction for planning queries, and RangeSet is a good library to implement it on. If it hadn’t been in Guava, we would have had to implement something like it ourselves. (In fact, I recall one Calcite PR that basically had its own implementation of RangeSet.) Julian > On Sep 29, 2020, at 7:44 AM, Vladimir Sitnikov <[email protected]> > wrote: > > Apparently, RangeSet is a @Beta API in Guava, and they stress that @Beta > APIs should not be used in libraries. > > I suggest we do something with that, otherwise, it results in a case where > Calcite enforces all the consumers to depend on @Beta API which > might disappear or drift. > > See https://github.com/google/guava/wiki/PhilosophyExplained#beta-apis > > It is literally the very first "important warning": > > https://github.com/google/guava#important-warnings > > 1, APIs marked with the @Beta annotation at the class or method level are > subject to change. > They can be modified in any way, or even removed, at any time. If your > code is a library itself > (i.e., it is used on the CLASSPATH of users outside your own control), > you should not use beta APIs unless you repackage them. If your code is a > library, > we strongly recommend using the Guava Beta Checker to ensure that you do > not use any @Beta APIs! > > Should we revert RangeSets? > Should we ask Guava to promote it from @Beta? > > Vladimir
