On Tue, Dec 4, 2018 at 2:14 PM Josh Elser <els...@apache.org> wrote: > > Phoenix depends on Avatica for its Phoenix Query Server. Avatica > requires Java8. Thus, the impasse. >
Generally our maintaining JDK7 support shouldn't limit the ability of any downstream user to require a newer JDK. Is there some context I'm missing? Are they manually recompiling some part of our codebase that doesn't work with JDK8? Or do they not want to have folks complaining to them for requiring a JDK update that we don't require? > I'd pose the question: are we really doing our users a service for > continuing to allow them to use Java7? Not trying to be contentious in > asking that -- I am just (happily) seeing fewer and fewer folks still on > Java7. Yes. Making it so downstream folks don't have to worry about certain categories of changes is the entire advantage of us declaring backward compatibility promises at all. JDK changes are a big deal in any deployment. As a project we already have a path forward for no longer worrying about maintaining Java 7 support; it's Apache HBase 2+. Providing advantages for that move and reducing the risk of updating to it is a straight forward way to remove our limitation on JDK features. IMHO, making it riskier to upgrade to newer 1.y minor versions is an undesirable way to drive that change.
