Java 1.4.2 or Java6?

[Tiago Espinha <ti...@espinhas.net>]

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? Also, is there a way to force ant to
use 1.6 when all the jdks are available?

Finally, for some background, the overload is the
String.replace(CharSequence, CharSequence);. On 1.4.2 there is only a
replace method in Strings that takes two chars and it doesn't allow us to
replace whole chunks of a string, so that's why I got the error. If I have
to make it 1.4.2-compatible I am also open to suggestions on replacing
chunks of a string, in this case with an empty string (so in essence,
removing whole pieces of a string a string).

Cheers,
Tiago

Re: Java 1.4.2 or Java6?

[Knut Anders Hatlen <Kn...@Sun.COM>]

Tiago Espinha <ti...@espinhas.net> writes:

> It is available in 1.4.2 indeed and that will have to do. The thing is that
> replaceAll uses regex and not regular string matching.
>
> I'm thinking I'll end up dropping the replacing altogether. This was just for
> pruning the output that I am parsing as I go, but I can just not prune it and
> it'll be fine anyway. The trade-off between doing a regex search and having to
> search through some more characters is probably balanced, and regex would
> introduce some more issues in the end.

Note that the String methods that use regex are not part of Foundation
Profile 1.1, so if the test uses those methods it'll have to be disabled
on the Java ME platforms.

-- 
Knut Anders

Re: Java 1.4.2 or Java6?

[Tiago Espinha <ti...@espinhas.net>]

It is available in 1.4.2 indeed and that will have to do. The thing is that
replaceAll uses regex and not regular string matching.

I'm thinking I'll end up dropping the replacing altogether. This was just
for pruning the output that I am parsing as I go, but I can just not prune
it and it'll be fine anyway. The trade-off between doing a regex search and
having to search through some more characters is probably balanced, and
regex would introduce some more issues in the end.

On Thu, Jun 25, 2009 at 1:42 PM, Kathey Marsden <kmarsdenderby@sbcglobal.net
> wrote:

> Tiago Espinha wrote:
>
>>
>> Finally, for some background, the overload is the
>> String.replace(CharSequence, CharSequence);. On 1.4.2 there is only a
>> replace method in Strings that takes two chars and it doesn't allow us to
>> replace whole chunks of a string, so that's why I got the error. If I have
>> to make it 1.4.2-compatible I am also open to suggestions on replacing
>> chunks of a string, in this case with an empty string (so in essence,
>> removing whole pieces of a string a string).
>>
>>  I think replaceAll is available on 1.4.2. Will that work for you?
>
>

Re: Java 1.4.2 or Java6?

[Kathey Marsden <km...@sbcglobal.net>]

Tiago Espinha wrote:
>
> Finally, for some background, the overload is the 
> String.replace(CharSequence, CharSequence);. On 1.4.2 there is only a 
> replace method in Strings that takes two chars and it doesn't allow us 
> to replace whole chunks of a string, so that's why I got the error. If 
> I have to make it 1.4.2-compatible I am also open to suggestions on 
> replacing chunks of a string, in this case with an empty string (so in 
> essence, removing whole pieces of a string a string).
>
I think replaceAll is available on 1.4.2. Will that work for you?

Re: Java 1.4.2 or Java6?

[Tiago Espinha <ti...@espinhas.net>]

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 <Kn...@sun.com>wrote:

> Tiago Espinha <ti...@espinhas.net> 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
> <exclude> 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 <jdk6home>/lib/jre/*.jar,
> <derbysrc>/tools/java/xalan.jar and <derbysrc>/classes/stubs/jdbc3, I
> think. But by doing this you risk introducing build breaks for others.
>
> --
> Knut Anders
>

Re: Java 1.4.2 or Java6?

[Knut Anders Hatlen <Kn...@Sun.COM>]

Tiago Espinha <ti...@espinhas.net> 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
<exclude> 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 <jdk6home>/lib/jre/*.jar,
<derbysrc>/tools/java/xalan.jar and <derbysrc>/classes/stubs/jdbc3, I
think. But by doing this you risk introducing build breaks for others.

-- 
Knut Anders