git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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>
> wrote:
> 
>> 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
>> if
>>> 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
>> points.
>> Another good step is to shade and relocate Guava so that downstream
>> projects do not have conflicts.
>> 
>> My 2 cents
>> Enrico
>> 
>> 
>>> 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
>> it
>>> to the whole code base. Many lines of code will change, and that
>> increases
>>> the chances of merge conflicts, so it’s important that we don’t make any
>>> changes in functionality in that commit.
>>> 
>>> Julian
>>> 
>>> 
>>>> 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
>> on
>>>> minimum JDK 8 this looks to be viable.  CALCITE-2259 identifies a few
>>> other
>>>> 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
>>> features
>>>> 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.
>>>> 
>>>> [1] https://issues.apache.org/jira/browse/SOLR-11763
>>>> [2] https://issues.apache.org/jira/browse/CALCITE-2259
>>>> 
>>>> Kevin Risden
>>> 
>>> --
>> 
>> 
>> -- Enrico Olivelli
>>