Peter Firmstone wrote:
Well this is a tough one, here are some ideas:

  1. Branch what we have now for release and simply reset the compiler
     flag, to jsr14, which buys time until we have a more modular
     build, then based on what we know then, decide if ongoing support
     for remote clients using Java 1.4 is feasible.  For this release,
     test on Java 1.4, 5 and 6.  We could adopt a policy that if a bug
     exists on Java 1.4 or 5, but not on 6, then the fix is to upgrade
     to Java 6.  Users would of course be free to submit a patch, but
     we wouldn't actively support the earlier platforms.
  2. Compile on JDK 1.6 and support only Java 5 and 6, drop support for
     communicating with remote Java 1.4 clients.  If we find that it is
     later possible to support Java 1.4 clients with the modular build,
     users can skip the current release.  Users can work around the
     Java 1.4 communication issue if they need to, by using proxy
     codebases from the previous release only.
...
I think you touched on something earlier, it's important we address ease of deployment.

In both cases, I think we want to encourage a move towards 6. Even in a corporate environment, it is often difficult to simultaneously upgrade to a new JVM for a lot of jobs, on different computers.

I'm interested in probing the path for a current 1.4 installation to 6 for each approach. The more I think about it, the more I feel that keeping 1.4 as a common language for proxies might be an advantage.

Patricia

Reply via email to