river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: JVM version policy Was: Re: Build failed in Hudson: River-trunk-jdk1.5 #3
Date Sat, 27 Nov 2010 18:11:16 GMT
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.


View raw message