tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Back-porting JSR-356 implementation to 7.0.x
Date Fri, 16 Aug 2013 01:34:25 GMT

On 8/15/13 6:47 PM, Mark Thomas wrote:
> This isn't going to be quite as simple as I first thought.
> The WebSocket client API requires Java SE 7 or later.
> The WebSocket server API requires Java EE 6 or later.
> Java EE 6 requires Java 6 or later.

Clarification: are you saying that Java EE requires that it be allowed
to run on JVMs as low as Java 6?

> The WebSocket server API depends on the WebSocket client API.
> The WebSocket client implementation makes extensive use of new Java 7
> non-blocking IO features.

Are any of these possible (albeit with some back-flips) with Java 6?
Perhaps one class (Java7NioShims) could be replaced with another
implementation (Java6NioShim) at runtime depending upon the current JVM?
I know nothing about the code involved... just stabbing in the dark.

> My conclusion from the above is that the back-port is going to require
> Java 7. That begs the question how to do that while keeping the main
> build Java 6 based.
> My (untested) plan is as follows:
> - Create a WebSocket module
> - Back-port (i.e. copy) the trunk code to that module
> - Build just that module with Java 7
> - Make the minimum changes necessary to get it to work
> - Modify the back-ported SCI so it only adds the filter if Java 7 is
> detected (going to need to ensure the SCI is executable on Java 6)
> - Ship Tomcat 7 with the WebSocket JARs

I'm not sure there's a better way, but the whole
compile-one-module-with-a-higher-version thing has been a small thorn in
the past (IIRC, Tomcat 6 had to be built with Java 6, but could be run
with Java 5) causing a mild amount of confusion. If this could be
avoided, I think it might be best.

Maybe we could package JSR-356-for-Tomcat7 as an optional module that
has a Java 7 prerequisite?


View raw message