On Mon, Jan 20, 2020 at 1:29 PM Ryan Schmitt <[email protected]> wrote:
> 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 Android concern might be valid, but it's not for me ATM. Aside from that, I think it is OK for public facing APIs to be Java 8 while internals might still be Java 7. This distinction is likely useless since reworking the API a la Java 8 I am sure would be best done soup to nuts. The worst of both worlds for me would be to release 5.0 on Java 7, then, as proposed earlier, 5.1 on Java 8. You'd then end up with an obsolete looking API by design. I might be reading our crowd incorrectly, but I do not see the appetite around here for thinking about a Java 8 based 6.0 to eliminate our "let's pretend we're on Java 8" util code. How do you see it? Gary > > 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 > > >
