Christopher Schultz <ch...@christopherschultz.net> wrote: >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?
Java EE 6 is the version Tomcat 7 uses. >> 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? The first thing I thought of. It is possible but would require a selector, poller and thread pool implementation plus associated plumbing. Java 7 looks like the better option at this point. >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. I know. I'm trying to find the minimum effort, minimum risk, minimum hassle solution but there isn't a perfect solution that I can see. >Maybe we could package JSR-356-for-Tomcat7 as an optional module that >has a Java 7 prerequisite? I'd really like to ship JSR-356 suport as standard. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
