I don't even think we should plan on starting a Java 8 release this spring. We still have a lot of bug-fixing and stabilization work ahead of us, and dealing with active development on 5.0 and 5.1/6.0 side-by-side is going to be a significant distraction. Additionally, the need to easily cherry-pick patches or git-merge one version into another will prevent us from making disruptive changes in the JDK8 code base, and here "disruptive" includes basic stuff like migrating to lambda syntax.
I would be more interested in seeing whether we can build a separate JDK8 module for 5.0 that adds CompletableFuture<T> interoperability. If such a thing is possible, I think it will scratch the same itch without the destabilizing effects on the codebase and development workflow. We've already done similar things in the form of :httpcore5-reactive, and of HttpAsyncClient on the 4.x line. On Tue, Jan 21, 2020 at 2:18 PM Michael Osipov <[email protected]> wrote: > Am 2020-01-19 um 15:03 schrieb Gary Gregory: > > 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. > > I am not totally against this, but do you really think that > stop-the-world and rewrite a lot of code for the sake of Java 8 will > help us? Will will throw us at least three months or more back. > > I would really get back to my proposal at GH: Move on with 5.0, keep it > for a year or so and start working on 6.0 in Spring with Java 8. > > Since we have learned what we can do better in the future, let's keep it > for the future. > > > - Java 7 is deader than a doornail and is a barrier to entry for > > contributors used to more modern Java versions. > > We have worse problem than sticking to Java 7, imho. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
