You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Kevin Risden <kr...@apache.org> on 2018/04/26 04:15:50 UTC
Calcite - JDK 8 and Use of Guava
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
Re: Calcite - JDK 8 and Use of Guava
Posted by Julian Hyde <jh...@apache.org>.
No worries. We all have day jobs. :)
I am still evolving that branch (e.g. I just did some experiments to see whether CacheLoader could benefit from lambdas) so let me know when you start work based on it and I’ll stop.
I think this effort will take a few weeks to evolve as I/we discover how Java 8 syntax can simplify things. I am pleased with how it’s going so far, and I’m in no particular hurry to finish it.
Julian
> On May 2, 2018, at 11:41 AM, Kevin Risden <kr...@apache.org> wrote:
>
> Sorry for the delay in getting back to this. I can definitely take a look
> at this and respond on CALCITE-2259. It might take me a few days.
>
> Kevin Risden
>
> On Mon, Apr 30, 2018 at 5:21 PM, Julian Hyde <jh...@apache.org> wrote:
>
>> 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 <kr...@apache.org> 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 <eo...@gmail.com>
>>> wrote:
>>>
>>>> Il gio 26 apr 2018, 06:55 Julian Hyde <jh...@apache.org> 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 <kr...@apache.org> 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
>>>>
>>
>>
Re: Calcite - JDK 8 and Use of Guava
Posted by Kevin Risden <kr...@apache.org>.
Sorry for the delay in getting back to this. I can definitely take a look
at this and respond on CALCITE-2259. It might take me a few days.
Kevin Risden
On Mon, Apr 30, 2018 at 5:21 PM, Julian Hyde <jh...@apache.org> wrote:
> 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 <kr...@apache.org> 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 <eo...@gmail.com>
> > wrote:
> >
> >> Il gio 26 apr 2018, 06:55 Julian Hyde <jh...@apache.org> 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 <kr...@apache.org> 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
> >>
>
>
Re: Calcite - JDK 8 and Use of Guava
Posted by Julian Hyde <jh...@apache.org>.
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 <kr...@apache.org> 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 <eo...@gmail.com>
> wrote:
>
>> Il gio 26 apr 2018, 06:55 Julian Hyde <jh...@apache.org> 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 <kr...@apache.org> 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
>>
Re: Calcite - JDK 8 and Use of Guava
Posted by Kevin Risden <kr...@apache.org>.
>
> 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 <eo...@gmail.com>
wrote:
> Il gio 26 apr 2018, 06:55 Julian Hyde <jh...@apache.org> 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 <kr...@apache.org> 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
>
Re: Calcite - JDK 8 and Use of Guava
Posted by Enrico Olivelli <eo...@gmail.com>.
Il gio 26 apr 2018, 06:55 Julian Hyde <jh...@apache.org> 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 <kr...@apache.org> 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
Re: Calcite - JDK 8 and Use of Guava
Posted by Julian Hyde <jh...@apache.org>.
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.
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 <kr...@apache.org> 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