I think it is probably fine to go with a single style of I/O for the lower layer transport; if we want to also provide a blocking interface I think it would be ok to write that as an adapter up at the HttpClient level.
On the Java 8 side, I think a major release (5.x) that generally has API breaking changes is an excellent opportunity to get onto a non-EOL version of Java! So I am also in favor of that. Jon On Wed, Sep 28, 2016 at 11:07 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > Starting to move to Java 8 is a nice idea. Let's do it. I could see all 5.0 > components being Java 8. > > Gary > > On Sep 28, 2016 7:39 AM, "Oleg Kalnichevski" <ol...@apache.org> wrote: > > > Folks > > > > The HTTP/2 transport in trunk has been shaping up reasonably well. I > > have made some good progress recently and am cautiously optimistic that > > there should be a HttpCore 5.0 alpha release with the new non-blocking > > HTTP/1.1 and HTTP/2 transports within a month or two. HttpClient 5.0 > > alpha should follow in Jan 2017. > > > > There is a few points I wanted to discuss and get some feedback upon. > > > > (1) I no longer see any reason to continue developing the classic > > (blocking) server side transport. We only use it for integration tests > > internally for integration tests and I feel there is no reason to not > > use non-blocking transport for all integration tests instead. > > > > (2) What would you say about HttpCore 5.0 remaining Java 7 compatible > > but HttpClient 5.0 requiring Java 8? > > > > I do not see HC 5.0 going GA any time sooner than Q4 2017. By that time > > Java 9 should be out and Java 8 might be approaching EOL. Two years ago > > Java 7 compatibility sounded like a good idea but it looks less so > > today. > > > > (3) Never ending trouble with logging toolkits. > > > > Should be remain faithful to Commons Logging or shall we finally migrate > > to SLF4J? > > > > What do you think? > > > > Oleg > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > >
