Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 88158 invoked from network); 25 Jun 2009 12:23:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Jun 2009 12:23:16 -0000 Received: (qmail 91912 invoked by uid 500); 25 Jun 2009 12:23:27 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 91867 invoked by uid 500); 25 Jun 2009 12:23:27 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 91859 invoked by uid 99); 25 Jun 2009 12:23:27 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Jun 2009 12:23:27 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_MESSAGE,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (athena.apache.org: transitioning domain of tiago@espinhas.net does not designate 209.85.219.211 as permitted sender) Received: from [209.85.219.211] (HELO mail-ew0-f211.google.com) (209.85.219.211) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Jun 2009 12:23:19 +0000 Received: by ewy7 with SMTP id 7so2139948ewy.7 for ; Thu, 25 Jun 2009 05:22:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.210.38.5 with SMTP id l5mr2059823ebl.53.1245932576700; Thu, 25 Jun 2009 05:22:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jun 2009 13:22:56 +0100 Message-ID: Subject: Re: Java 1.4.2 or Java6? From: Tiago Espinha To: derby-dev@db.apache.org Content-Type: multipart/alternative; boundary=001517478be8a5f833046d2b48f1 X-Virus-Checked: Checked by ClamAV on apache.org --001517478be8a5f833046d2b48f1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thank you for your input Knut. To be honest the test should run on all JDKs. There's no real reason that it shouldn't run on 1.4.2 other than the String.replace() issue, but I'll find a workaround for that. Tiago Espinha On Thu, Jun 25, 2009 at 1:19 PM, Knut Anders Hatlen wrote: > Tiago Espinha writes: > > > Hello everyone, > > > > I have been around for a couple of months and I still manage to learn > > something new everyday; also, I manage to find something everyday about > which > > I am not sure how I should address. > > > > This time I am wondering about the Java version. Basically I have two > setups: > > on one of them I have *only* jdk 1.6 and on the other I have the whole > set of > > jdks (1.4.2, 1.5 and 1.6). > > > > Yesterday, I made a change and it compiled normally against Sun's jdk1.6 > - > > however, when I ported it over to the other setup to run suites.All, it > > wouldn't compile since it was attempting to use 1.4.2 (on this one I have > all > > the jdks declared in the ant.properties file) and the change uses an > overload > > that was only introduced in either 1.5 or 1.6. > > > > Since this is a change I made on a test, should I make sure it is > backwards > > compatible with 1.4.2 or is 1.6 fine? > > Unless there's a good reason why the test should not run on 1.4.2 or on > Java ME, I think it's best to make it backwards compatible. If it is > only supposed to run on newer JDKs, you'd also have to change the build > script so that it is always compiled against the correct class library > (otherwise the build will fail for those who have a setup with 1.4.2), > and there must also be logic in the test's suite() method or in the > _Suite class to prevent the test from running on older JDKs (otherwise > it'll fail in many of the nightly tests). > > > Also, is there a way to force ant to use 1.6 when all the jdks are > > available? > > If you only want to use it for some of the classes, locate the build.xml > file that contains the build target for those classes and add an > tag that excludes the files in question. Then create a new > javac target (if it does not already exist) which includes the files and > where you change source/target/classpath as needed. To use 1.6, > classpath would need to contain ${java16compile.classpath}. See > java/engine/org/apache/derby/impl/services/build.xml for an example. > > If you want to change it for the entire setup, so that the setup with > 1.4.2, 1.5 and 1.6 behaves like the one with only 1.6, you'd need to set > java14compile.classpath and java15compile.classpath manually in > ant.properties. They need to include /lib/jre/*.jar, > /tools/java/xalan.jar and /classes/stubs/jdbc3, I > think. But by doing this you risk introducing build breaks for others. > > -- > Knut Anders > --001517478be8a5f833046d2b48f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you for your input Knut. To be honest the test should run on all JDKs= . There's no real reason that it shouldn't run on 1.4.2 other than = the String.replace() issue, but I'll find a workaround for that.

Tiago Espinha

On Thu, Jun 25, 2009 at= 1:19 PM, Knut Anders Hatlen <Knut.Hatlen@sun.com> wrote:
Tiago Espinha <t= iago@espinhas.net> writes:

> Hello everyone,
>
> I have been around for a couple of months and I still manage to learn<= br> > something new everyday; also, I manage to find something everyday abou= t which
> I am not sure how I should address.
>
> This time I am wondering about the Java version. Basically I have two = setups:
> on one of them I have *only* jdk 1.6 and on the other I have the whole= set of
> jdks (1.4.2, 1.5 and 1.6).
>
> Yesterday, I made a change and it compiled normally against Sun's = jdk1.6 -
> however, when I ported it over to the other setup to run suites.All, i= t
> wouldn't compile since it was attempting to use 1.4.2 (on this one= I have all
> the jdks declared in the ant.properties file) and the change uses an o= verload
> that was only introduced in either 1.5 or 1.6.
>
> Since this is a change I made on a test, should I make sure it is back= wards
> compatible with 1.4.2 or is 1.6 fine?

Unless there's a good reason why the test should not run on 1.4.2= or on
Java ME, I think it's best to make it backwards compatible. If it is only supposed to run on newer JDKs, you'd also have to change the build=
script so that it is always compiled against the correct class library
(otherwise the build will fail for those who have a setup with 1.4.2),
and there must also be logic in the test's suite() method or in the
_Suite class to prevent the test from running on older JDKs (otherwise
it'll fail in many of the nightly tests).

> Also, is there a way to force ant to use 1.6 when all the jdks are
> available?

If you only want to use it for some of the classes, locate the build.= xml
file that contains the build target for those classes and add an
<exclude> tag that excludes the files in question. Then create a new<= br> javac target (if it does not already exist) which includes the files and where you change source/target/classpath as needed. To use 1.6,
classpath would need to contain ${java16compile.classpath}. See
java/engine/org/apache/derby/impl/services/build.xml for an example.

If you want to change it for the entire setup, so that the setup with
1.4.2, 1.5 and 1.6 behaves like the one with only 1.6, you'd need to se= t
java14compile.classpath and java15compile.classpath manually in
ant.properties. They need to include <jdk6home>/lib/jre/*.jar,
<derbysrc>/tools/java/xalan.jar and <derbysrc>/classes/stubs/jd= bc3, I
think. But by doing this you risk introducing build breaks for others.

--
Knut Anders

--001517478be8a5f833046d2b48f1--