Sorry, I don't think that makes sense. It's rarely a problem to run 1.5 code in a 1.6 JVM. Instead the problem is usually that there is no 1.6 JVM available on the system. I've had two real-world cases: older OS (Fedora Core 3 and Mac OS 10.4) and licensing (an redistribution agreement with Sun that covered only 1.4 and 1.5).
Chris -----Original Message----- From: Patricia Shanahan [mailto:p...@acm.org] Sent: Friday, July 01, 2011 12:57 PM To: dev@river.apache.org Subject: A thought on JVM migration I've seen some discussion of using a separate JVM for security. Does it also provide a solution to the problem of JVM migration in a continuously operating River-based system? Suppose the objective is to migrate from 1.5 to 1.6. The first step would be to get each client and server into a state in which it can recognize that a proxy needs 1.6, and spawn a 1.6 JVM, with 1.6 versions of River jars, to run it. That can be done on a gradual, machine-by-machine basis. The second step is to replace each program installation with its JVM 1.6 version, again on a machine-by-machine basis. During this phase, there will be times when a 1.5 application needs to run a proxy that needs 1.6, and solves the problem by spawning a 1.6 JVM to run it. At the end of the second step the system is fully 1.6, and the 1.5 JVM and libraries can be uninstalled. If a service is implemented on multiple servers, and the servers are updated at different times, the service remains continuously available. Does this make any sense? Patricia