From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Kris Jurka <books(at)ejurka(dot)com> |
Cc: | Dave Cramer <pg(at)fastcrypt(dot)com>, pgsql-jdbc(at)postgreSQL(dot)org |
Subject: | Re: gcj has a lot of complaints about 8.1-405 release |
Date: | 2006-03-30 18:06:44 |
Message-ID: | Pine.OSF.4.61.0603302102480.228269@kosh.hut.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On Tue, 28 Mar 2006, Kris Jurka wrote:
>
>
> On Mon, 27 Mar 2006, Tom Lane wrote:
>
>> BTW, one Red Hatter had this to say:
>>
>>> Yeah, AFAIAC this is a bug in ant. Really, the build file should be using
>>> ${java.version} instead of ${ant.java.version} to avoid this problem,
>>> IMHO.
>>> I ran into a similar issue with the Eclipse SDK.
>>
>
> The difference is that java.version will return things like 1.4.2_08 instead
> of just 1.4, so they are not equivalent. ant doesn't offer a lot of tools to
> parse such a string, the best you could do would be a global substring match.
> Trying to find 1.4 would match 1.1.4 as well as 1.4.2 though. Since we don't
> support 1.1 builds we could do this, but it seems a little fragile with
> perhaps other vendors using different format strings. The best solution for
> older ant users might be to duplicate the checks ant makes for
> ant.java.version in our own build file. That way we can put in the latest
> updates and not require an upgrade.
How about java.specification.version? AFAIK, it should do just what we
need.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | João Paulo Ribeiro | 2006-03-31 10:02:54 | Behaviour of setAutoCommit may not be completely correct. |
Previous Message | Tom Arthurs | 2006-03-30 03:22:20 | Re: Where does meta-data come from? |