Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <453E466D.6090200@amberpoint.com>
Date: Tue, 24 Oct 2006 09:59:25 -0700
From: Bryan Pendleton <bpendleton@amberpoint.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: JUnit "TestConfiguration.defaultSuite()" and 1.3 JVMs...
References: <45390EA7.1060908@gmail.com> <4539141D.7020408@sun.com>
 <45391859.9090902@apache.org> <45392961.1060100@sun.com>
 <45392D99.4080601@apache.org> <45393B7D.9090702@sun.com>
 <453949CC.9000102@apache.org>
In-Reply-To: <453949CC.9000102@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

>> How about a transition period? Perhaps we should wait a month after 
>> Java SE 6 goes GA and then poll the community to see if anyone objects 
>> to requiring Java SE 6 at that time?
> 
> I'm worried that we are narrowing the pool of potential developers when 
> I think we still want to grow the community. From this blog entry it 
> seems even in Feb 2006 most Java developers were using JDK 1.4. Somehow 
> I don't see a sudden jump to Java SE 6 one month after it goes GA.

Just wanted to add my 2 cents, as follows:

First, I'd like us to be conservative about when we eliminate support for
older JVMs. Dropping support for 1.3 seems reasonable, but I think
1.4 will be in widespread use for several more years at least.

Second, I think it's possible to distinguish between the developer
community and the user community. Requiring a certain setup to build and
modify the code is not necessarily the same as requiring a certain setup
to download and use the pre-built code.

Last, and somewhat in contradiction with my second point, I think it's
useful for the build-and-test setup that the development community uses
to be as close as possible to the execution-time setup that most users use,
because it helps reduce the chance that we accidentally build in a
dependency on some Java feature that we didn't knowingly mean to depend on.

thanks,

bryan