Description of problem: The summary pretty much says it all. For whatever reason, postgresql-jdbc-9.0.801-2.fc15 appears to lack JDBC4 support. This causes any attempt to use the Connection.createArrayOf() method to throw an AbstractMethodError. Simply rebuilding the SRPM on my fully updated Fedora 15 system (including updates-testing) seems to fix the issue. Version-Release number of selected component (if applicable): postgresql-jdbc-9.0.801-2.fc15.x86_64 How reproducible: 100% Steps to Reproduce: 1. Run a Java program that uses the Connection.createArrayOf() method with the PostgreSQL JDBC driver. Actual results: AbstractMethodError is thrown. Expected results: No error. Method invocation should work (assuming program is correct).
AFAICT there is no substantial difference between the released RPM and what I get building today on an F-15 machine --- the .so's are not identical, but the jars are, so it's pretty hard to believe that JDBC4 support is present in one and not the other. So I'm confused by your statement that a rebuild fixes it, and I really doubt that just rebuilding will help. Are you perhaps using a nonstandard JVM? As for the actual problem, I'd appreciate a concrete test case.
(In reply to comment #1) > As for the actual problem, I'd appreciate a concrete test case. Actually, never mind that part: a quick look in the postgresql-jdbc sources shows that they only configure JDBC4 support when built in a 1.6 or later JVM. Since GCJ currently provides a 1.5 JVM, the lack of JDBC4 support is unsurprising. Digging in the koji build logs confirms that at least back to F-8 (as far back as we have the build logs) postgresql-jdbc reports "Configured build for the JDBC3g edition driver". I have recently switched postgresql-jdbc to a non-GCJ build in F-16 and up, and that does compile the JDBC4 support since it's in a 1.6 JVM. So if we were going to fix this in F-15, the way to do it would be to change the build method. I'm a bit hesitant to do that in a stable release branch though. I'm still curious as to how you got a JDBC4 build without changing the SRPM ... did you manually force no GCJ support?
(In reply to comment #2) > I'm still curious as to how you got a JDBC4 build without changing the SRPM ... > did you manually force no GCJ support? All I did was bump the release, add a changelog entry, and rebuild. I had actually flagged GCJ as the culprit (since JDBC4 is a Java 1.6 thing) and hacked up the SPEC file to preserve the OpenJDK-built JAR as postgresql-jdbc4.jar. Then I thought to try simply rebuilding the SRPM. (Someday, I'll learn to try the easy way *first*.) Can you tell from the logs what JDK was used to build the released package? Would a mock environment use GCJ?
(In reply to comment #3) > I had actually flagged GCJ as the culprit (since JDBC4 is a Java 1.6 thing) > and hacked up the SPEC file to preserve the OpenJDK-built JAR as > postgresql-jdbc4.jar. Then I thought to try simply rebuilding the SRPM. > (Someday, I'll learn to try the easy way *first*.) Still don't see how that would give a different result than I'm getting. > Can you tell from the logs what JDK was used to build the released package? Yes: 1.5 > Would a mock environment use GCJ? Yes, at least it does when I try it. There's some really hard-to-follow code in the spec file that allows the build environment to influence the choice of GCJ or not: %global _gcj_support 1 %global gcj_support %{?_with_gcj_support:1}%{!?_with_gcj_support:%{?_without_gcj_support:0}%{!?_without_gcj_support:%{?_gcj_support:%{_gcj_support}}%{!?_gcj_support:0}}} I suspect you have got some environmental setting that's allowing the non-GCJ path to be taken when you build it. I've avoided messing with that %global expression since I suppose it's mandated by some JPP convention somewhere, but it's sure ugly ...
(In reply to comment #4) > (In reply to comment #3) > > Would a mock environment use GCJ? > > Yes, at least it does when I try it. > > There's some really hard-to-follow code in the spec file that allows the build > environment to influence the choice of GCJ or not: > > %global _gcj_support 1 > > %global gcj_support > %{?_with_gcj_support:1}%{!?_with_gcj_support:%{?_without_gcj_support:0}%{!?_without_gcj_support:%{?_gcj_support:%{_gcj_support}}%{!?_gcj_support:0}}} > > I suspect you have got some environmental setting that's allowing the non-GCJ > path to be taken when you build it. I've avoided messing with that %global > expression since I suppose it's mandated by some JPP convention somewhere, but > it's sure ugly ... Uugh. I wouldn't touch that. Does mock pull in OpenJDK at all? It could be as simple as OpenJDK being present on my system (and preferred by alternatives, which is the default).
(In reply to comment #5) > Does mock pull in OpenJDK at all? It does not, see the build logs at http://koji.fedoraproject.org/koji/buildinfo?buildID=226903 > It could be as simple as OpenJDK being > present on my system (and preferred by alternatives, which is the default). [ experiments a bit... ] Hah: having java-1.6.0-openjdk present on the machine does not change the results, but installing java-1.6.0-openjdk-devel does. I'm a bit surprised that the GCJ build goes through with JDBC4-specific code in the jars, but evidently it does. So at this point it seems we could do nothing (leaving this to change in F-16), or abandon the GCJ build, or add a BuildRequires to suck in java-1.6.0-openjdk-devel. ISTM both of the latter two choices have some potential for unexpected breakage.
(In reply to comment #6) > So at this point it seems we could do nothing (leaving this to change in F-16), > or abandon the GCJ build, or add a BuildRequires to suck in > java-1.6.0-openjdk-devel. ISTM both of the latter two choices have some > potential for unexpected breakage. Since you're weird enough to worry about breakage in Fedora ... ;-) Personally, I would vote for adding the openjdk-devel requirement in F16. (Is OpenJDK available on all Fedora architectures?) On RHEL 5 & 6 (if necessary) maybe a separate OpenJDK-built postgresql-jdbc4 package?
Upon further poking around, I observe that mysql-connector-java has been buildrequiring java-1.6.0-openjdk-devel in GCJ builds for quite some time; it's even that way in RHEL6, and we do have builds for all arches there. So I guess I'm worrying over nothing. Will make it so.
postgresql-jdbc-9.0.801-4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/postgresql-jdbc-9.0.801-4.fc15
Please test this --- I don't use Java that much and am not in a good position to see if anything broke.
(In reply to comment #10) > Please test this --- I don't use Java that much and am not in a good position > to see if anything broke. Appears to be working fine here.
Package postgresql-jdbc-9.0.801-4.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing postgresql-jdbc-9.0.801-4.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/postgresql-jdbc-9.0.801-4.fc15 then log in and leave karma (feedback).
postgresql-jdbc-9.0.801-4.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.