Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=sbcglobal.net;
  h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
  b=repGDlydTays56e2DudEfTLBRTPUPPw9QVkY8CZNxB+BPRDXq8t5mozMqTrY1gBlKzrctqwiSnlebkCc0vI0KaHfB/iIPDQdShgwq3o/sSzzZRyBVvti2CbRbnhv7M8g8BKdnFrPhdoCLwvxV2xnatElqGrJGBk9bRDBIInA9JU=
  ;
Message-ID: <4E0CD9D9.8050405@sbcglobal.net>
Date: Thu, 30 Jun 2011 13:17:29 -0700
From: Mike Matrigali <mikem_app@sbcglobal.net>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Sunsetting support for Derby on JVM 1.4
References: <4E0CA6D2.5010607@oracle.com>
In-Reply-To: <4E0CA6D2.5010607@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rick Hillegas wrote:
> No-one on the user list has objected to sunsetting support for JVM 1.4 
> starting with Derby 10.9. There is still some interest in supporting 
> small devices on CDC/FP 1.1. Sunsetting support for JVM 1.4 would mean 
> that we would stop running regression tests on that platform (starting 
> with Derby 10.9) and we would not spend a lot of effort chasing problems 
> on that platform.
> 
> Because we would continue supporting CDC/FP 1.1, we would not be able to 
> modernize the bulk of Derby code to take advantage of language features 
> introduced by Java 5. These features include enums, annotations, and 
> generics.
> 
> I would like to move ahead with sunsetting support for JVM 1.4. I'm 
> happy to call a formal vote to ratify this change if people think that 
> would be useful. What are your thoughts?
> 
> Thanks,
> -Rick
> 
I am not sure what it means in open source for such a vote.  If anyone 
wants to run tests and fix issues for JVM 1.4 or any other JVM that 
seems fine to me.  Individual contributors as always can decide which 
features and bugs to work on.  It would be different if we were deciding 
to actively check
in things to the default Derby set of features that we know would not 
work against JVM 1.4 architecture.

As I understand it nothing is changing.
The default set of Derby 10.9 is designed to work
against the JDK 1.4 spec, and allows extensions against more recent 
specs for features designed to be "optional and/or enhanced".