Re: gcj has a lot of complaints about 8.1-405 release

So I tried to build the current release using latest gcj, and it blew up
real good: 27 hard errors and 60 warnings. My java-fu is not that
strong, but a lot of these look like problems to me. Comments?

regards, tom lane

On Mon, 27 Mar 2006, Tom Lane wrote:

> So I tried to build the current release using latest gcj, and it blew up
> real good: 27 hard errors and 60 warnings. My java-fu is not that
> strong, but a lot of these look like problems to me. Comments?
>

The source of the problem is that ant is being run in a 1.5 JVM, but the
java compiler is defaulting to 1.4 source code and fails to recognize the
1.5 syntax. Currently ant must be run in the same JVM version as the
compiler expects. A workaround for you would be to add source="1.5" to
the javac tag in build.xml.

Kris Jurka

Looks like the real errors is that it is trying to compile java 1.5
code and doesn't have the ability.

What level of java does gjc support ?

Dave
On 27-Mar-06, at 4:58 PM, Tom Lane wrote:

> <mime-attachment.gz>

Tom,

Can you give me the output of ant -verbose on that platform ?

Dave
On 27-Mar-06, at 4:58 PM, Tom Lane wrote:

> <mime-attachment.gz>

Dave Cramer <pg(at)fastcrypt(dot)com> writes:
> Can you give me the output of ant -verbose on that platform ?

I sent Dave the full output off-list, but the critical part seems to be
right at the start:

Apache Ant version 1.6.5 compiled on March 6 2006
Buildfile: build.xml
Detected Java version: 1.5 in: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
Detected OS: Linux

If the java package version means what I think it means, then this is
misdetecting the version. Is this our fault, or is something screwy
in Red Hat's build environment?

regards, tom lane

Tom,

Yeah, you read it right.... one more thing please

output of java -version

Dave
On 27-Mar-06, at 5:34 PM, Tom Lane wrote:

> Dave Cramer <pg(at)fastcrypt(dot)com> writes:
>> Can you give me the output of ant -verbose on that platform ?
>
> I sent Dave the full output off-list, but the critical part seems
> to be
> right at the start:
>
> Apache Ant version 1.6.5 compiled on March 6 2006
> Buildfile: build.xml
> Detected Java version: 1.5 in: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
> Detected OS: Linux
>
> If the java package version means what I think it means, then this is
> misdetecting the version. Is this our fault, or is something screwy
> in Red Hat's build environment?
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

Dave Cramer <pg(at)fastcrypt(dot)com> writes:
> Yeah, you read it right.... one more thing please
> output of java -version

java version "1.4.2"
gij (GNU libgcj) version 4.1.0 20060304 (Red Hat 4.1.0-3)

Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

regards, tom lane

On Mon, 27 Mar 2006, Tom Lane wrote:

> Apache Ant version 1.6.5 compiled on March 6 2006
> Detected Java version: 1.5 in: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
>
> If the java package version means what I think it means, then this is
> misdetecting the version. Is this our fault, or is something screwy
> in Red Hat's build environment?
>

Your version of ant determines it is a 1.5 JVM by being able to load the
java.lang.Readable interface which shouldn't exist in a 1.4 JVM. Newer
versions of ant (2 days old) check for java.net.Proxy instead.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39027

Kris Jurka

Hmmm.... wierd.... you'd think that should be enough information to
figure out that it's version 1.4.2

Other than Kris's suggestion, I'm not sure how to help, unless I
could get access to a similiarly configured box.

I'm thinking the java config files must be setup to tell it that it's
java 1.5 somewhere

Dave
On 27-Mar-06, at 6:18 PM, Tom Lane wrote:

> Dave Cramer <pg(at)fastcrypt(dot)com> writes:
>> Yeah, you read it right.... one more thing please
>> output of java -version
>
> java version "1.4.2"
> gij (GNU libgcj) version 4.1.0 20060304 (Red Hat 4.1.0-3)
>
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

Kris Jurka <books(at)ejurka(dot)com> writes:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39027

Ah-hah. I'll twist some arms to get this into Red Hat's build system ASAP.
Many thanks for the clue!

regards, tom lane

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.

Comments?

regards, tom lane

Certainly from Kris's post this is a bug in Ant which has been
corrected in the latest versions.

Dave
On 27-Mar-06, at 10:09 PM, 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.
>
> Comments?
>
> regards, tom lane
>

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.

Kris Jurka

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

On Thu, 30 Mar 2006, Heikki Linnakangas wrote:

> How about java.specification.version? AFAIK, it should do just what we
> need.
>

Indeed it does, I've put this into our build.xml along with an explicit
failure message when someone tries a JDK1.6 compile.

Kris Jurka

I am also really excited about GCJ/Classpath support, since this would
allow users to use postgres from java applications without relying on
proprietary software.

Just because of interrest, has anybody successfully used the jdbc
driver with gnu-classpath based JVMs?

Thanks, lg Clemens

2006/4/29, Kris Jurka <books(at)ejurka(dot)com>:
>
>
> On Thu, 30 Mar 2006, Heikki Linnakangas wrote:
>
> > How about java.specification.version? AFAIK, it should do just what we
> > need.
> >
>
> Indeed it does, I've put this into our build.xml along with an explicit
> failure message when someone tries a JDK1.6 compile.
>
> Kris Jurka
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>