Mark, 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? -chris
signature.asc
Description: OpenPGP digital signature
