Thread: Can't build postgresql-jdbc-8.2-505 on Fedora 7
So I tried to import 8.2-505 into Red Hat's development tip, and it blew
up on me with errors that look like Java version incompatibilities,
for instance
[javac] 53. ERROR in /builddir/build/BUILD/postgresql-jdbc-8.2.505/org/postgresql/jdbc3g/Jdbc3gArray.java (at line
17)
[javac] public class Jdbc3gArray extends org.postgresql.jdbc2.AbstractJdbc2Array implements java.sql.Array
[javac] ^^^^^^^^^^^
[javac] The type Jdbc3gArray must implement the inherited abstract method Array.getArray(long, int, Map)
[javac] ----------
[javac] 57. ERROR in /builddir/build/BUILD/postgresql-jdbc-8.2.505/org/postgresql/jdbc3g/Jdbc3gArray.java (at line
24)
[javac] public Object getArray(Map < String, Class < ? >> map) throws SQLException
[javac] ^^^^^^^^^^^^^
[javac] Syntax error, parameterized types are only available if source level is 5.0
[javac] ----------
The identical SRPM builds fine on my Fedora Core 6 workstation, although
I notice it says
[echo] Configured build for the JDBC3 edition driver with SSL
where the failed build has
[echo] Configured build for the JDBC3g edition driver with SSL
FC6 has java-1.4.2 where 7 has java-1.5.0.
Not being much of a Java guru, I could use some help fixing this.
As a short-term measure, I'd be happy to de-rate the thing to plain
JDBC3, but am not sure where to poke to make that happen. In the longer
term, what needs to be fixed to make it compatible? Should I be filing
a bug against gcj, or is this a driver portability problem?
regards, tom lane
Tom, On 23-Apr-07, at 6:50 PM, Tom Lane wrote: > So I tried to import 8.2-505 into Red Hat's development tip, and it > blew > up on me with errors that look like Java version incompatibilities, > for instance > > [javac] 53. ERROR in /builddir/build/BUILD/postgresql- > jdbc-8.2.505/org/postgresql/jdbc3g/Jdbc3gArray.java (at line 17) > [javac] public class Jdbc3gArray extends > org.postgresql.jdbc2.AbstractJdbc2Array implements java.sql.Array > [javac] ^^^^^^^^^^^ > [javac] The type Jdbc3gArray must implement the inherited > abstract method Array.getArray(long, int, Map) > [javac] ---------- > > [javac] 57. ERROR in /builddir/build/BUILD/postgresql- > jdbc-8.2.505/org/postgresql/jdbc3g/Jdbc3gArray.java (at line 24) > [javac] public Object getArray(Map < String, Class < ? >> map) > throws SQLException > [javac] ^^^^^^^^^^^^^ > [javac] Syntax error, parameterized types are only available if > source level is 5.0 > [javac] ---------- This is a problem with the source level of the output. If 1.4.2 can build it, then java 1.5.0 certainly should be able to. > The identical SRPM builds fine on my Fedora Core 6 workstation, > although > I notice it says > > [echo] Configured build for the JDBC3 edition driver with SSL > > where the failed build has > > [echo] Configured build for the JDBC3g edition driver with SSL > > FC6 has java-1.4.2 where 7 has java-1.5.0. > > Not being much of a Java guru, I could use some help fixing this. > As a short-term measure, I'd be happy to de-rate the thing to plain > JDBC3, but am not sure where to poke to make that happen. In the > longer > term, what needs to be fixed to make it compatible? Should I be > filing > a bug against gcj, or is this a driver portability problem? Oh, your using gcj ??? Any chance I can get a login ? > > regards, tom lane > > ---------------------------(end of > broadcast)--------------------------- > TIP 6: explain analyze is your friend
Dave Cramer <pg@fastcrypt.com> writes:
> This is a problem with the source level of the output. If 1.4.2 can
> build it, then java 1.5.0 certainly should be able to.
Yeah, somebody seems confused about which language level is in use,
but I dunno exactly which side's wrong. If you think there's a
reasonable probability that this is gcj's fault, I can go pester
Red Hat's java guys.
> Oh, your using gcj ???
Yeah, RH went over to gcj some time ago.
> Any chance I can get a login ?
Sorry, I can't get you access to Red Hat's build machines (I have to go
through bureaucratic pushups to get shell access myself). If you can
tell me specific things to look at I'm happy to do the legwork. The
alternative would probably be for you to download and install F7 Test 4,
or whichever is the latest available snapshot. It's a big download
though :-(
regards, tom lane
Tom,
Try changing this line in build.xml
<javac classpath="${srcdir}" srcdir="${srcdir}" destdir="${builddir}"
debug="${debug}">
to
<javac classpath="${srcdir}" srcdir="${srcdir}" destdir="${builddir}"
debug="${debug}" source="1.5" >
Dave
On 23-Apr-07, at 7:12 PM, Tom Lane wrote:
> Dave Cramer <pg@fastcrypt.com> writes:
>> This is a problem with the source level of the output. If 1.4.2 can
>> build it, then java 1.5.0 certainly should be able to.
>
> Yeah, somebody seems confused about which language level is in use,
> but I dunno exactly which side's wrong. If you think there's a
> reasonable probability that this is gcj's fault, I can go pester
> Red Hat's java guys.
>
>> Oh, your using gcj ???
>
> Yeah, RH went over to gcj some time ago.
>
>> Any chance I can get a login ?
>
> Sorry, I can't get you access to Red Hat's build machines (I have
> to go
> through bureaucratic pushups to get shell access myself). If you can
> tell me specific things to look at I'm happy to do the legwork. The
> alternative would probably be for you to download and install F7
> Test 4,
> or whichever is the latest available snapshot. It's a big download
> though :-(
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
Tom Lane wrote: > So I tried to import 8.2-505 into Red Hat's development tip, and it blew > up on me with errors that look like Java version incompatibilities, > for instance > > [javac] 53. ERROR in /builddir/build/BUILD/postgresql-jdbc-8.2.505/org/postgresql/jdbc3g/Jdbc3gArray.java (at line17) > [javac] public class Jdbc3gArray extends org.postgresql.jdbc2.AbstractJdbc2Array implements java.sql.Array > [javac] ^^^^^^^^^^^ > [javac] The type Jdbc3gArray must implement the inherited abstract method Array.getArray(long, int, Map) > [javac] ---------- > > [javac] 57. ERROR in /builddir/build/BUILD/postgresql-jdbc-8.2.505/org/postgresql/jdbc3g/Jdbc3gArray.java (at line24) > [javac] public Object getArray(Map < String, Class < ? >> map) throws SQLException > [javac] ^^^^^^^^^^^^^ > [javac] Syntax error, parameterized types are only available if source level is 5.0 > [javac] ---------- > > The identical SRPM builds fine on my Fedora Core 6 workstation, although > I notice it says > > [echo] Configured build for the JDBC3 edition driver with SSL > > where the failed build has > > [echo] Configured build for the JDBC3g edition driver with SSL > > FC6 has java-1.4.2 where 7 has java-1.5.0. It looks like ant's java.specification.version is reporting 1.5 (hence configuring the build for "jdbc3g" -- JDBC3 + generics), but the default ant <javac> task (with no source=... parameter) is invoking a compiler that is expecting 1.4 source. I'm guessing that's because gcj is implementing 1.5 but defaulting to 1.4 source (which is different to the Sun JVM) You could try adding 'source="1.5"' as an attribute of the <javac> task. Or if you're running Ant 1.7 you can pass -Dant.build.javac.source=1.5 on the ant command line. (both untested) -O
Oliver Jowett <oliver@opencloud.com> writes:
> You could try adding 'source="1.5"' as an attribute of the <javac> task.
I'll give that a shot tomorrow; thanks to you and Dave for the suggestion.
> Or if you're running Ant 1.7 you can pass -Dant.build.javac.source=1.5
> on the ant command line. (both untested)
This would be easier (no patch needed), but it looks like FC7's ant is
still 1.6.5, so no dice.
regards, tom lane
Tom Lane wrote: > Oliver Jowett <oliver@opencloud.com> writes: >> You could try adding 'source="1.5"' as an attribute of the <javac> task. > > I'll give that a shot tomorrow; thanks to you and Dave for the suggestion. We should probably be explicitly setting a source version to match the source we're giving to javac to catch exactly this sort of case, anyway.. It certainly can't hurt since we know that e.g. the 1.5 source isn't going to build if interpreted as 1.4. -O
Oliver Jowett <oliver@opencloud.com> writes:
>>> You could try adding 'source="1.5"' as an attribute of the <javac> task.
That seems to have done the trick --- thanks for the suggestion.
> We should probably be explicitly setting a source version to match the
> source we're giving to javac to catch exactly this sort of case,
> anyway.. It certainly can't hurt since we know that e.g. the 1.5 source
> isn't going to build if interpreted as 1.4.
+1 ...
regards, tom lane
On Tue, 24 Apr 2007, Oliver Jowett wrote: > We should probably be explicitly setting a source version to match the source > we're giving to javac to catch exactly this sort of case, anyway.. It > certainly can't hurt since we know that e.g. the 1.5 source isn't going to > build if interpreted as 1.4. > I've applied the attached patch to 8.0 -> 8.3 dev which sets the source level based on java.specification.version. Kris Jurka