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