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