Re: Calcite - JDK 8 and Use of Guava
I’ve completed my initial work on this, and have committed to my dev branch https://github.com/julianhyde/calcite/tree/2259-lambda <https://github.com/julianhyde/calcite/tree/2259-lambda>. It would be great if you could continue work on this Kevin. If so, respond in the comments of https://issues.apache.org/jira/browse/CALCITE-2259 <https://issues.apache.org/jira/browse/CALCITE-2259>.
> On Apr 27, 2018, at 7:44 PM, Kevin Risden <krisden@xxxxxxxxxx> wrote:
>> Can you hold off making code changes for a few days, until I can commit
>> the branch?
> Definitely can hold off wasn't immediately going to start on this other
> than initial research. Will add details to CALCITE-2259
> Kevin Risden
> On Thu, Apr 26, 2018 at 1:07 AM, Enrico Olivelli <eolivelli@xxxxxxxxx>
>> Il gio 26 apr 2018, 06:55 Julian Hyde <jhyde@xxxxxxxxxx> ha scritto:
>>> In general I would agree that we should replace Guava with JDK features
>>> the JDK has them.
>>> However, we must preserve compatibility, so if an API uses Guava Function
>>> or Predicate or Supplier or ImmutableList then we should probably keep it
>>> that way. Or let’s discuss it.
>> It would be a very good improvement to drop Guava and in general third
>> party classes from public API.
>> For the limited use of Calcite I am doing I am not aware of such critical
>> Another good step is to shade and relocate Guava so that downstream
>> projects do not have conflicts.
>> My 2 cents
>>> Converting Preconditions.checkNotNull to Objects.requireNonNull seems
>>> pretty safe.
>>> I’ve started work on 2259 in a branch that is not yet committed. (Mainly
>>> converting anonymous classes to lambdas at this point.) Can you hold off
>>> making code changes for a few days, until I can commit the branch? In
>>> CALCITE-2259, make a list of things that we should do, and we can apply
>>> to the whole code base. Many lines of code will change, and that
>>> the chances of merge conflicts, so it’s important that we don’t make any
>>> changes in functionality in that commit.
>>>> On Apr 25, 2018, at 9:15 PM, Kevin Risden <krisden@xxxxxxxxxx> wrote:
>>>> There is a discussion in SOLR-11763 about Guava and limiting its use by
>>>> replacing with native JDK 8 alternatives. Since Calcite 0.16.0 is now
>>>> minimum JDK 8 this looks to be viable. CALCITE-2259 identifies a few
>>>> JDK 8 nice to haves.
>>>> One example looks to be:
>>>> * Preconditions.checkNotNull(obj); // Guava
>>>> * Objects.requireNonNull(obj); // JDK 8
>>>> Are there any concerns with looking into this? Are there any known
>>>> of Guava that are necessary? I know some adapters might require Guava.
>>>> I am just starting to look at this and figured I'd ask before diving in
>>>> head first. I would start with core and then work out to other modules.
>>>>  https://issues.apache.org/jira/browse/SOLR-11763
>>>>  https://issues.apache.org/jira/browse/CALCITE-2259
>>>> Kevin Risden
>> -- Enrico Olivelli