The right time to upgrade to JDK8 would have been three years ago, before reams of callback code got written, and everything could have been built around CompletableFuture from the ground up. At this point, switching would be the worst of both worlds: we'd have a JDK7-style codebase without JDK7 compatibility. (I'm told some people still like JDK7. Android developers, I guess?) Additionally, it would further delay the GA release with additional months of refactoring and language-level upgrades.
The only argument for upgrading to JDK8 that gives me pause is that we would have access to default interface methods. I don't think long-term library evolution is feasible without them, and I believe this is why the Log4j2 API is being upgraded to JDK8 in the 2.13 release. On Sun, Jan 19, 2020 at 6:04 AM Gary Gregory <[email protected]> wrote: > I propose that the upcoming HttpCore and HttpClient version 5.0 should > require Java 8, not 7. > > - This will allow us to use java.time.Duration instead of cooking up our > own TimeValue. Even if we want to keep the TimeValue and Timeout > abstraction, they can implemented using a java.time.Duration. > - This will allow us to use java.util.function instead of cooking up our > own org.apache.hc.core5.function > - This will avoid all sorts of ugly if and when we do adopt Java 8 within > 5.x as surely we should offer Duration APIs where we now use TimeValue. > Same for org.apache.hc.core5.function. > - This will allow us to use lambdas where appropriate. > - Java 7 is deader than a doornail and is a barrier to entry for > contributors used to more modern Java versions. > > Thoughts? > > Gary >
