Bug 730588 - postgresql-jdbc built without JDBC4 support
Summary: postgresql-jdbc built without JDBC4 support
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: postgresql-jdbc
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tom Lane
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-14 18:39 UTC by Ian Pilcher
Modified: 2013-07-03 03:38 UTC (History)
2 users (show)

Fixed In Version: postgresql-jdbc-9.0.801-4.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-26 18:55:31 UTC


Attachments (Terms of Use)

Description Ian Pilcher 2011-08-14 18:39:58 UTC
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).

Comment 1 Tom Lane 2011-08-15 16:29:40 UTC
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.

Comment 2 Tom Lane 2011-08-15 17:07:23 UTC
(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?

Comment 3 Ian Pilcher 2011-08-15 17:19:16 UTC
(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?

Comment 4 Tom Lane 2011-08-15 17:38:52 UTC
(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 ...

Comment 5 Ian Pilcher 2011-08-15 18:33:02 UTC
(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).

Comment 6 Tom Lane 2011-08-15 18:49:21 UTC
(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.

Comment 7 Ian Pilcher 2011-08-15 21:06:40 UTC
(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?

Comment 8 Tom Lane 2011-08-16 01:12:16 UTC
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.

Comment 9 Fedora Update System 2011-08-16 02:53:58 UTC
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

Comment 10 Tom Lane 2011-08-16 02:57:04 UTC
Please test this --- I don't use Java that much and am not in a good position to see if anything broke.

Comment 11 Ian Pilcher 2011-08-16 14:30:15 UTC
(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.

Comment 12 Fedora Update System 2011-08-17 01:19:03 UTC
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).

Comment 13 Fedora Update System 2011-08-26 18:55:25 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.