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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> wrote: >>> >>>> Il gio 26 apr 2018, 06:55 Julian Hyde <[email protected]> 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 <[email protected]> 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 >>>> >> >>
