Re: Dropping support for Guava versions earlier than 14

(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

Re: Dropping support for Guava versions earlier than 14

The main reason why we don't shade protobuf is MR jobs for bulk load. We are using hbase-protocol in the classpath and clash between shaded and unshaded protobufs happen. Actually I'm not sure whether we still need this (I mean hbase-protocol in the classpath). Actually shading doesn't work well

Re: Dropping support for Guava versions earlier than 14

What about APIs with byte[] parameters? Lot's of APIs have this, but almost all of the time the byte[] is immutable. That's kind of in the same category as what-if String were mutable, no? On Tue, Sep 6, 2016 at 2:11 PM, Julian Hyde wrote: > How bad would it be for API

Re: Dropping support for Guava versions earlier than 14

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

Re: Dropping support for Guava versions earlier than 14

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

Re: Dropping support for Guava versions earlier than 14

We were bit by guava comparator chain wrt to booleans. On Tuesday, September 6, 2016, Andrew Purtell wrote: > I've been bitten three times: once by CacheBuilder, once by Stopwatch, > once by Service. > > > On Sep 6, 2016, at 12:10 PM, Julian Hyde

Re: Dropping support for Guava versions earlier than 14

I've been bitten three times: once by CacheBuilder, once by Stopwatch, once by Service. > On Sep 6, 2016, at 12:10 PM, Julian Hyde 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

Re: Dropping support for Guava versions earlier than 14

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 wrote: > > No

Re: Dropping support for Guava versions earlier than 14

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 exps”. It is very important that everyone,

Re: Dropping support for Guava versions earlier than 14

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

Re: Dropping support for Guava versions earlier than 14

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 wrote: > I'm not keen on shading

Re: Dropping support for Guava versions earlier than 14

Calcite will work with Guava 16 and currently does use the Cassandra 3.x driver. -- Michael Mior michael.m...@gmail.com On Sep 3, 2016 05:03, "CPC" wrote: > Cassandra driver 3.x require min guava 16.0.1. If it detects an earlier > version in classpath it stops working. > > On

Re: Dropping support for Guava versions earlier than 14

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

Re: Dropping support for Guava versions earlier than 14

Use hbase-shaded-client as Maven dep (1.1 and up) > On Sep 3, 2016, at 10:12 AM, James Taylor 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

Re: Dropping support for Guava versions earlier than 14

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 wrote: > James - When Stack is finished coprocessors will work with shaded > protobuf. Not yet. > > > On Sep 3,

Re: Dropping support for Guava versions earlier than 14

James - When Stack is finished coprocessors will work with shaded protobuf. Not yet. > On Sep 3, 2016, at 10:07 AM, James Taylor wrote: > > Also agree - shading of guava & protobuf would be super valuable. Phoenix > ended up not supporting shading of protobuf because

Re: Dropping support for Guava versions earlier than 14

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

Re: Dropping support for Guava versions earlier than 14

+1 on shading guava/protobuf. On Sat, Sep 3, 2016 at 9:48 AM, Andrew Purtell 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

Re: Dropping support for Guava versions earlier than 14

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

Re: Dropping support for Guava versions earlier than 14

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...

Re: Dropping support for Guava versions earlier than 14

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 wrote: > > Cassandra driver 3.x require min guava 16.0.1. If it detects an earlier > version in

Re: Dropping support for Guava versions earlier than 14

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" 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

Re: Dropping support for Guava versions earlier than 14

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

Re: Dropping support for Guava versions earlier than 14

+1 to drop. Storm depends on Guava 16.0.1. - Jungtaek Lim (HeartSaVioR) On Saturday, September 3, 2016, Julian Hyde 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 < >

Dropping support for Guava versions earlier than 14

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 I’d like to use RangeSet, which was introduced in Guava 14. Would anyone have a problem if we made