Hi, ALPN implementation from Jetty does not require Java 8 but it requires OpenJDK (not Oracle and at least OpenJDK 1.7.0u40), in addition there is a specific version of ALPN for each minor version of OpenJDK, and it has to be in the boot classpath of the jvm. I don't think we need to rush to Java 8 because of HTTP/2. We can do just like Jetty which still works on Java 7 and only checks at runtime for OpenJDK and ALPN when you want to turn on SPDY or HTTP/2
2015-02-28 14:35 GMT+01:00 Oleg Kalnichevski <[email protected]>: > (1) HTTP/2 multiplexing is simply impossible to implement efficiently > with classic (blocking) I/O. A single HTTP/2 connection now represents > multiple full duplex streams of data. The connection can simply not > block doing just one thing, like writing out a lengthy message content > body in one stream while completely blocking out all other streams. > While I cannot completely rule out the idea of implementing just a > subset of HTTP/2 with blocking I/O at some point, it does look like we > should focus on exclusively on non-blocking code and seriously consider > getting rid of blocking components at some point. > > (2) HTTP/2 invalidates a lot of previous design decisions > > (*) Given that data is now being transferred in fairly small chunks for > multiple independent streams it is no longer important or even desirable > to let non-blocking protocol handlers have direct access to the > underlying connection channel. This pretty much invalidates the entire > design of the I/O reactor layer. The I/O reactor layer is likely to > require a complete re-design and rewrite. > > (*) Multiplexing and TLS encryption makes zero-copy transfer mode pretty > much impossible and irrelevant terms of performance optimization. > > (3) Fully compliant deployments of HTTP/2 are _required_ to negotiate > supported protocols using TLS Application-Layer Protocol Negotiation > Extension (RFC 7301) which is not even supported by Java at the moment > [1] and likely to become available in Java 9 only. There is a hack of > sort developed by Jetty folks that make this extension somehow work with > Java 8 but I have not looked at it yet. Regardless, it looks like we > have to upgrade to Java 8 no matter what. > > This, again, poses a difficult question whether we should rush HC 5.0 > with HTTP/1.1 only and introduce HTTP/2 in HC 6.0. This would enable us > to delay inevitable upgrade to Java 8/9 for those folks who are only > interested in HTTP/1.1. > > (4) We might need introduce logging support at HttpCore level simply > because the transport logic is massively more complex now. Back to > logging wars. > > (5) Client side connection pooling becomes much, much less relevant. > Probably even irrelevant. This eliminates a considerable advantage HC > have over competing client side HTTP implementations. > > (6) We should be able to re-use all existing protocol handling code with > HTTP/2. > > The good news is that HTTP/2 is conceptually elegant and very flexible. > It addresses pretty much all short-comings of HTTP/1.1 I can think of. > > Oleg > > PS: There likely to be other thoughts I would want to share as my work > progresses. More posts to come. > > PPS: I am working on HTTP/2 frame handling code at the moment (the low > level data frame transport stream multiplexer code will be based upon). > If anyone wants to see early code please let me know > > [1] https://bugs.openjdk.java.net/browse/JDK-8062848 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
