Given that the Java 5 end-of-life is October 30, I don't think we should be bending over backwards for Java 5 support in a release that we are only now just planning, and will come after at least one point release (2.5.1), if not more if we move to a more time-based release schedule. (But that's the subject of another email thread!)

However, I would like to provide as many options as possible to Jython users, especially those running in a container where they can't control the specific JVM level.

So a reasonable compromise might be that we will target Java 6, but Jython 2.6 runs on Java 5 with these limitations:
Reduced functionality is a reality of a sandbox environment like the JVM. Certain things are not available when running in the context of a servlet container or Google App Engine, as just a couple of examples. This does not reduce the importance of being able to do other tasks for that same code base when not running in a restricted fashion.

An alternative is that we will simply require Java 6, and backport fixes, performance optimizations, etc., for a while. This would be easier than it's against 2.2, for a number of reasons (continuous integration, same internal type system, continuing active support by core Python dev).

- Jim

On Thu, Jun 11, 2009 at 7:12 PM, Leo Soto M. <> wrote:
On Thu, Jun 11, 2009 at 8:45 PM, Frank Wierzbicki<> wrote:
> BTW I expect we will be maintaining 2.5 for at least a few years, so
> JDK 5 people will continue to have a good option for Jython.

I think this is the stronger point.

People wanting to stay on a hyper-stable really-old platform, can just
use our own hyper-stable really-old releases.

This applies right now for the Java1.4/Jython2.2 combination and will
apply to Java5/Jython2.5 on the future.
Leo Soto M.

Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
Jython-dev mailing list

Jim Baker