Have you talked to your upstreams about planned obsolescence? And about supporting a range of versions, so that everyone isn’t locked down forever.
Julian > On Sep 6, 2016, at 8:37 PM, Andrew Purtell <[email protected]> wrote: > > We are stuck because our upstreams are stuck. > > Not moving up that minimum would not worsen the situation. > >> On Sep 6, 2016, at 8:34 PM, Julian Hyde <[email protected] >> <mailto:[email protected]>> wrote: >> >> As I said, Calcite doesn’t require a particular version of Guava. We support >> any version newer than 11. >> >> But we would really, really appreciate it if you (and other downstream >> projects) moved off the obsoleted old versions. >> >> Julian >> >>> On Sep 6, 2016, at 8:29 PM, Andrew Purtell <[email protected]> wrote: >>> >>> Downstreamers might be stuck. >>> >>> Bringing together a number of components written against different versions >>> of Guava, you will find both forward and backward incompatibilities are >>> possible if stepping outside of a narrow range, and even at the same time. >>> If Calcite is required by something and itself requires yet another version >>> of Guava the viable intersection could become the null set. >>> >>> As a library, export of Guava types is unfriendly. >>> >>>> On Sep 6, 2016, at 7:18 PM, Julian Hyde <[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]>>> wrote: >>>> >>>> Alternative proposal: >>>> We keep Guava in the public API. >>>> Down-streamers can use whatever version of Guava they choose. >>>> >>>> This is what we do today. It’s working fine (except that the down >>>> streamers seem to want to stay on old versions forever). >>>> >>>> Julian >>>> >>>> >>>>> On Sep 6, 2016, at 6:43 PM, Josh Elser <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> (from the peanut gallery) >>>>> >>>>> I have no strong opinions but find myself presently leaning towards Ted's >>>>> suggestions. >>>>> >>>>> Ideally, I think that we should not expose things in a "public API" which >>>>> we do not have the ability to guarantee compatibility of. A round-about >>>>> way of saying "Calcite public API should only be Calcite classes or Java >>>>> 'standard library' classes". Included Guava classes in the API would be >>>>> disallowed. The basic reasoning behind this is that it guarantees that we >>>>> have full control of our "destiny" without having to worry about >>>>> dependency versions. >>>>> >>>>> On the quick read of Ted's suggestion, it matches that (hide the Guava >>>>> class in the API's implementation with a generic type in the API). But, I >>>>> can also appreciate the problems you outline as well, Julian. >>>>> >>>>> Julian Hyde wrote: >>>>>> Yes, I misread your suggestion. I see now you are suggesting a >>>>>> compromise. The worst that can happen is that the API users make a few >>>>>> unnecessary defensive copies, or due to missing documentation they have >>>>>> to spend a little longer researching the API in order to discover that >>>>>> it is “safe”. >>>>>> >>>>>> I am not particularly inclined to compromise, because I would like Java >>>>>> to be a high level language. An immutable collection is inherently >>>>>> simpler than a mutable collection. Consider the problem of >>>>>> contravariance[1] in generics: if I have a function >>>>>> >>>>>> int countLegs(List<? extends Animal> animals) >>>>>> >>>>>> and I pass into it an argument of type >>>>>> >>>>>> List<? extends Dog> >>>>>> >>>>>> then the Java compiler rejects it, because it thinks that the function >>>>>> might try to add a Cat to the list. But we know that this is impossible, >>>>>> because countLegs does not modify the list. If immutability is part of >>>>>> the declared type of the list, the type validation rules can be looser. >>>>>> >>>>>> Julian >>>>>> >>>>>> [1] >>>>>> https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)<https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)> >>>>>> >>>>>> <https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3Chttps://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3E><https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3Chttps://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3E><https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3Chttps://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3E >>>>>> >>>>>> <https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3Chttps://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3E%3E%3Chttps://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3Chttps://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3E><https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3Chttps://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3E >>>>>> >>>>>> <https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3Chttps://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)%3E>>> >>>>>> >>>>>> >>>>>>> On Sep 6, 2016, at 2:41 PM, Ted Dunning<[email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>> <mailto:[email protected]>>>> wrote: >>>>>>> >>>>>>> Julian, >>>>>>> >>>>>>> I think you miss the point of my suggestion. >>>>>>> >>>>>>> String is not called ImmutableString. The contract of no immutability is >>>>>>> carried by outside tribal knowledge and documentation. It is enforced by >>>>>>> not allowing mutation. >>>>>>> >>>>>>> If you declare a List, but assign an ImmutableList, you are in a similar >>>>>>> situation except that the tribal knowledge has to be more forceful >>>>>>> because >>>>>>> of the normal expectation of List as mutable. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Wed, Sep 7, 2016 at 7:11 AM, Julian Hyde<[email protected] >>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>> <mailto:[email protected]>>>> wrote: >>>>>>>> >>>>>>>> How bad would it be for API designers and users if java.lang.String >>>>>>>> were >>>>>>>> mutable? I would say really, really bad. You could add a lot of >>>>>>>> comments to >>>>>>>> the API documentation, but you’d never really be sure that everyone was >>>>>>>> adhering to the contract. >>>>>>>> >>>>>>>>> On Sep 6, 2016, at 1:59 PM, Ted Dunning<[email protected] >>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>> <mailto:[email protected]>>>> wrote: >>>>>>>>> >>>>>>>>> What is so bad about declaring that variable as a List and making it >>>>>>>>> an >>>>>>>>> ImmutableList underneath? >>>>>>>>> >>>>>>>>> Guard it in the programmer's mind by comments and naming. And if they >>>>>>>> don't >>>>>>>>> believe you, it still can't be changed. >>>>>>>>> >>>>>>>>> This avoids Guava leakage in the API and still gives you (nearly) all >>>>>>>>> of >>>>>>>>> the benefits of the ImmutableList type. >>>>>>>>> >>>>>>>>> Kind of give a little to get a little. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Wed, Sep 7, 2016 at 5:10 AM, Julian Hyde<[email protected] >>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>> <mailto:[email protected]>>>> wrote: >>>>>>>>>> >>>>>>>>>> What is so bad about Guava? I have always found it to be a high >>>>>>>>>> quality >>>>>>>>>> library. I hear that they have broken backwards compatibility on one >>>>>>>>>> or >>>>>>>> two >>>>>>>>>> occasions, but I’ve never been affected by that personally. >>>>>>>>>> >>>>>>>>>>> On Sep 6, 2016, at 12:04 PM, Andrew Purtell<[email protected] >>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>> <mailto:[email protected]>>>> >>>>>>>> wrote: >>>>>>>>>>> No argument that naming should set expectations of immutability if >>>>>>>> that's >>>>>>>>>>> what should be conveyed, but Guava types (or Guava anything) is a >>>>>>>>>>> means >>>>>>>>>> to >>>>>>>>>>> an end that can inflict significant pain on downstreamers. >>>>>>>>>>> >>>>>>>>>>>> On Tue, Sep 6, 2016 at 11:59 AM, Julian Hyde<[email protected] >>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>> <mailto:[email protected]>> <mailto:[email protected] >>>>>>>>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>>>>>>>> <mailto:[email protected]>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Calcite’s API has a large surface area. The API consists not just >>>>>>>>>>>> of >>>>>>>>>>>> method calls, but also data objects. For example, the Project class >>>>>>>> [1] >>>>>>>>>>>> represents a project node in a relational algebra expression. Its >>>>>>>>>>>> main >>>>>>>>>>>> field is “public final ImmutableList<RexNode> exps”. It is very >>>>>>>>>> important >>>>>>>>>>>> that everyone, especially the client, understands that that list is >>>>>>>>>>>> immutable. When you create a Project, you do not need to make a >>>>>>>>>> defensive >>>>>>>>>>>> copy of the list because no one is able to modify it. >>>>>>>>>>>> >>>>>>>>>>>> Imagine the mayhem if java.lang.String was mutable. As an API >>>>>>>>>>>> designer >>>>>>>>>> you >>>>>>>>>>>> would have to spell out whether the caller or the provider is >>>>>>>>>>>> allowed >>>>>>>> to >>>>>>>>>>>> change the string, and at what time. You would worry about thread >>>>>>>>>> safety, >>>>>>>>>>>> if the string has been shared with another thread. Well, I believe >>>>>>>> that >>>>>>>>>>>> Guava immutable collections prevent the same kinds of mayhem. I >>>>>>>>>>>> would >>>>>>>>>> call >>>>>>>>>>>> that good API design. >>>>>>>>>>>> >>>>>>>>>>>> The immutable collections and functions are in every Guava >>>>>>>>>>>> version, so >>>>>>>>>> we >>>>>>>>>>>> really don’t care which Guava version we use, as long as it is not >>>>>>>>>> shaded. >>>>>>>>>>>> Julian >>>>>>>>>>>> >>>>>>>>>>>> [1] https://calcite.apache.org/apidocs/org/apache/calcite/ >>>>>>>>>>>> <https://calcite.apache.org/apidocs/org/apache/calcite/> >>>>>>>>>>>> rel/core/Project.html<https://calcite.apache.org/ >>>>>>>>>>>> <https://calcite.apache.org/> >>>>>>>>>>>> apidocs/org/apache/calcite/rel/core/Project.html> >>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 3, 2016, at 6:02 PM, Andrew >>>>>>>>>>>>>> Purtell<[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> I wouldn't call embedding Guava types in a public API either a >>>>>>>> service >>>>>>>>>>>> for users nor good API design, given the pain I've personally seen >>>>>>>>>>>> it >>>>>>>>>>>> inflict on multiple projects given Google's uncaring nature on >>>>>>>>>>>> cross >>>>>>>>>>>> version compatibility. >>>>>>>>>>>>>> On Sep 3, 2016, at 5:35 PM, Jacques Nadeau<[email protected] >>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>> wrote: >>>>>>>>>>>>>> Do you have a sense of how often we expose these? >>>>>>>>>>>>>> >>>>>>>>>>>>>> One random thought, shade Guava and continue to expose the >>>>>>>>>> shaded.guava >>>>>>>>>>>>>> classes in public APIs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> People could choose to use the unshaded or shaded. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, Sep 3, 2016 at 11:26 AM, Julian Hyde<[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>> wrote: >>>>>>>>>>>>>>> I'm not keen on shading Guava, because I want to include some of >>>>>>>>>>>>>>> Guava's classes in Calcite's public API: for example >>>>>>>>>>>>>>> ImmutableList >>>>>>>>>> and >>>>>>>>>>>>>>> Function. Using these classes in APIs makes better APIs. They >>>>>>>> should >>>>>>>>>>>>>>> be in the JDK, but sadly they're not, so we use Guava. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Calcite's policy has been to support a wide range of Guava >>>>>>>>>>>>>>> versions >>>>>>>>>>>>>>> but to drop support for really old versions. We can use >>>>>>>>>>>>>>> features in >>>>>>>>>>>>>>> newer versions via reflection, as long as we don't introduce a >>>>>>>>>>>>>>> link >>>>>>>>>>>>>>> dependency (i.e. we call via reflection) and we can provide >>>>>>>> fallback >>>>>>>>>>>>>>> for older versions. All of this is identical to our policy for >>>>>>>> JDKs, >>>>>>>>>>>>>>> really. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> All we need is that our dependencies move off the really old >>>>>>>> versions >>>>>>>>>>>>>>> in a timely fashion. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Julian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, Sep 3, 2016 at 10:20 AM, Andrew Purtell >>>>>>>>>>>>>>> <[email protected] <mailto:[email protected]>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> Use hbase-shaded-client as Maven dep (1.1 and up) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sep 3, 2016, at 10:12 AM, James Taylor< >>>>>>>> [email protected] <mailto:[email protected]>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> Does shading of protobuf on the HBase client work (or is that >>>>>>>>>>>> dependent >>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>> that brave work Stack is doing)? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sat, Sep 3, 2016 at 10:10 AM, Andrew Purtell< >>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> James - When Stack is finished coprocessors will work with >>>>>>>> shaded >>>>>>>>>>>>>>>>>> protobuf. Not yet. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Sep 3, 2016, at 10:07 AM, James Taylor< >>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Also agree - shading of guava& protobuf would be super >>>>>>>> valuable. >>>>>>>>>>>>>>> Phoenix >>>>>>>>>>>>>>>>>>> ended up not supporting shading of protobuf because of >>>>>>>>>> difficulties >>>>>>>>>>>>>>>>>> getting >>>>>>>>>>>>>>>>>>> it to work (maybe because HBase dependency?). I think we >>>>>>>> support >>>>>>>>>>>>>>> shading >>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>> Guava, though. Is that correct, Sergey? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Sat, Sep 3, 2016 at 10:02 AM, Jacques Nadeau< >>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> +1 on shading guava/protobuf. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Sat, Sep 3, 2016 at 9:48 AM, Andrew Purtell< >>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Since Calcite should become a widely used library (smile) >>>>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>> think it >>>>>>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>>>>>> be prudent to shade Guava and protobuf if Calcite depends >>>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>> them. >>>>>>>>>>>>>>> Then >>>>>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>>>> will play very nicely indeed on the classpath no matter >>>>>>>>>>>>>>>>>>>>> what >>>>>>>>>>>>>>> versions >>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>>> required by calling code. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Jacques - Good lord. Let me see about shading HBase use of >>>>>>>>>>>> Guava, or >>>>>>>>>>>>>>>>>>>>> eliminating it. Unfortunately that will be no help in the >>>>>>>> short >>>>>>>>>>>>>>> term. >>>>>>>>>>>>>>>>>>>>> Related, our Stack is wrestling with shading protobuf >>>>>>>> already, >>>>>>>>>>>> and >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>> neck >>>>>>>>>>>>>>>>>>>>> deep in the Swamp of Classloading at the moment. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Sep 3, 2016, at 9:06 AM, Jacques Nadeau< >>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> It isn't a real solution but in Drill we solved the HBase >>>>>>>>>>>>>>>>>>>> incompatibility >>>>>>>>>>>>>>>>>>>>>> issue on the server side (for tests only) by patching >>>>>>>>>>>>>>>>>>>>>> Guava >>>>>>>> 18 >>>>>>>>>>>> to >>>>>>>>>>>>>>>>>> allow >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> HBase Guava calls that are missing. They are really quite >>>>>>>>>>>> trivial >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>> support Andrew's arguments that Guava is the devil... >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/drill/blob/master/exec/java- >>>>>>>>>>>>>>>>>>>>> exec/src/main/java/org/apache/drill/exec/util/GuavaPatcher. >>>>>>>>>> java >>>>>>>>>>>>>>>>>>>>>> On Sat, Sep 3, 2016 at 8:16 AM, Andrew Purtell< >>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> While that seems very unfriendly of them, the main >>>>>>>>>>>>>>>>>>>>>>> issue is >>>>>>>>>>>> Guava >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> devil (and protobuf is a minor demon). Would shading be >>>>>>>>>>>>>>>>>>>>>>> an >>>>>>>>>>>> option? >>>>>>>>>>>>>>>>>>>>>>>> On Sep 3, 2016, at 2:03 AM, CPC<[email protected]> >>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> Cassandra driver 3.x require min guava 16.0.1. If it >>>>>>>> detects >>>>>>>>>>>> an >>>>>>>>>>>>>>>>>>>> earlier >>>>>>>>>>>>>>>>>>>>>>>> version in classpath it stops working. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Sep 3, 2016 04:26, "Julian Hyde"<[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> James& Andrew, I hear you. We’ll stay on Guava 12 if >>>>>>>>>>>>>>>>>>>>>>>>> we >>>>>>>>>> have >>>>>>>>>>>>>>> to. >>>>>>>>>>>>>>>>>>>>>>>>> But can we try an experiment to see if it’s possible >>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>> get >>>>>>>>>>>> away >>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>>> 14? >>>>>>>>>>>>>>>>>>>>>>>>> I propose that Maryann (who is developing the branch >>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>> Phoenix >>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>>>>>>>>>>>> Calcite) tries running with https://github.com/apache/ >>>>>>>>>>>>>>>>>>>>> calcite/pull/277 >>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/calcite/pull/277>. If we >>>>>>>>>> discover >>>>>>>>>>>>>>>>>>>> problems, >>>>>>>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>>>>>> can try various solutions, like make the >>>>>>>>>>>>>>>>>>>>>>>>> DateRangeRules >>>>>>>>>>>>>>> disabled by >>>>>>>>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>>>>>>>>>> (these, and the Druid adapter, are the only parts of >>>>>>>>>> Calcite >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>> need >>>>>>>>>>>>>>>>>>>>>>>>> Guava 14), or even copy the Guava classes that we >>>>>>>>>>>>>>>>>>>>>>>>> need. >>>>>>>> If >>>>>>>>>>>> there >>>>>>>>>>>>>>>>>>>>> aren’t >>>>>>>>>>>>>>>>>>>>>>>>> problems, it means that we’ve slipped out of the >>>>>>>>>>>>>>>>>>>>>>>>> shackles >>>>>>>>>> of >>>>>>>>>>>>>>>>>> inertia >>>>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>>>> are trying to drag us into an early grave. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Julian >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Sep 2, 2016, at 5:35 PM, James Taylor< >>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On the server-side, HBase depends on Guava 12 >>>>>>>>>>>>>>>>>>>>>>>>>> (because >>>>>>>>>>>> Hadoop >>>>>>>>>>>>>>>>>>>> depends >>>>>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>>>>>>> the same). For that reason, we've made sure Phoenix >>>>>>>>>>>>>>>>>>>>>>>>>> can >>>>>>>>>> work >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>>>> version too. Phoenix may not need to depend on >>>>>>>>>>>>>>>>>>>>>>>>>> Calcite >>>>>>>> on >>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> server-side, >>>>>>>>>>>>>>>>>>>>>>>>>> and Phoenix and HBase both have shading, so there >>>>>>>>>>>>>>>>>>>>>>>>>> may be >>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>> avenues >>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>> escape. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for the muddled answer. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Sep 2, 2016 at 5:21 PM, Andrew Purtell< >>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Use of Guava 14 introduces at least a compile time >>>>>>>>>> problem >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>> HBase, >>>>>>>>>>>>>>>>>>>>>>>>> upon >>>>>>>>>>>>>>>>>>>>>>>>>>> which Phoenix depends, so I'm not sure Phoenix can >>>>>>>>>>>>>>>>>>>>>>>>>>> move >>>>>>>>>>>> off of >>>>>>>>>>>>>>>>>> 13. >>>>>>>>>>>>>>>>>>>>> I'd >>>>>>>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>>>>> happy to be proven wrong. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Sep 2, 2016 at 4:35 PM, Julian Hyde< >>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> Calcite currently supports a wide range of Guava >>>>>>>>>> versions, >>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>>>>>>> 12.0.1 >>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>> 19.0*. For https://issues.apache.org/ >>>>>>>>>>>>>>> jira/browse/CALCITE-1334< >>>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/CALCITE-1334> >>>>>>>> I’d >>>>>>>>>>>>>>> like to >>>>>>>>>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>>>>>>>>>>> RangeSet, which was introduced in Guava 14. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Would anyone have a problem if we made Calcite’s >>>>>>>> minimum >>>>>>>>>>>>>>> Guava >>>>>>>>>>>>>>>>>>>>>>> version >>>>>>>>>>>>>>>>>>>>>>>>>>>> 14.0.1? >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I see that Hive uses 14.0.1, Phoenix uses 13, Drill >>>>>>>> uses >>>>>>>>>>>> 18. >>>>>>>>>>>>>>>>>>>>>>>>>>>> Julian >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> * Except for the Druid adapter, which requires 14; >>>>>>>>>>>>>>>>>>>>>>>>>>>> see >>>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/CALCITE-1325< >>>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/CALCITE-1325> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> - Andy >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Problems worthy of attack prove their worth by >>>>>>>>>>>>>>>>>>>>>>>>>>> hitting >>>>>>>>>>>> back. - >>>>>>>>>>>>>>>>>>>> Piet >>>>>>>>>>>>>>>>>>>>>>> Hein >>>>>>>>>>>>>>>>>>>>>>>>>>> (via Tom White) >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> - Andy >>>>>>>>>>> >>>>>>>>>>> Problems worthy of attack prove their worth by hitting back. - Piet >>>>>>>> Hein >>>>>>>>>>> (via Tom White)
