commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [all] The JDK1.5 issue [was: [net] JDK 1.4+ Branch?]
Date Mon, 30 Jan 2006 00:44:47 GMT
On 1/29/06, Stephen Colebourne <> wrote:
> I'd like to broaden the original [net] thread and ask how is commons
> going to handle JDK1.5? Or in the case of [net], is a JDK1.4 branch
> worthwhile?
> So far, commons has stuck with JDK 1.2/1.3 pretty much across the board.
> This is because
> a) JDK1.4 doesn't give that many benefits over 1.3
> b) a lot of people use 1.3 still (Websphere etc)
> c) limited developer resource to manage multiple branches
> So, my proposal is that [net], and other commons projects jump from a
> 1.2/1.3 base now, to a 1.5 base for the future. I believe that we are
> now starting to see 1.5 move forwards, perhaps towards the tipping point
> of much wider adoption. JDK1.5 can change radically the API design
> through generic and enums and this gives the opportunity for new
> development and new life to some of these projects. (New development
> often attracts new committers)
> I can't comment on the specifics of the [net] case, but I'd like commons
> as a whole to think seriously about how to handle the JDK1.5 issue.
> (As you may guess, my opinion is to skip 1.4 and go for 1.5 branches.)

As I indicated briefly before, IMO, we need to encourage 1.4 or Tiger
branches. Its an indication that we are moving forward as a community
rather than stagnating. We understand there are many people who have
to use <= 1.3, many times for reasons beyond their control -- thats
why so many of our components support those JDKs.

While creating a branch to push up the JDK version, which version is
chosen should be upto the developers creating the branch, I wouldn't
want to rule out 1.4 if anyone sees value in it or is not ready to go
to Tiger yet. I also think we shouldn't worry as much about the lack
of developer resources. Its takes one developer to start a branch, and
time will tell if it becomes successful and gets incorporated in a
future (presumably major version) release of the component.

If developers are willing, the fact that new ideas within a component
require a higher JDK version should never be the *only* limiting
factor for the introduction of these ideas.


> Stephen

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message