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