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