commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <>
Subject Re: [dbcp] update DBCP2 to require JDBC 4.1 (Java 7) WAS svn commit: r1431496 - in /commons/proper/dbcp/trunk: ./ src/java/org/apache/commons/dbcp2/ src/java/org/apache/commons/dbcp2/cpdsadapter/ src/java/org/apache/commons/dbcp2/datasources/ src/test/org/apache/commons/dbcp2/ src/test/org/apache/commons/dbc...
Date Tue, 28 May 2013 20:55:55 GMT
Le 28/05/2013 21:47, Gary Gregory a écrit :

> Something seems out of bounds here. Strictly speaking I know we deliver
> sources and we provide a jar as a convenience.
> The source we deliver comes with a clear definition through the POM on how
> to build it. We say, the source is Java version X and the target Java
> version Y, where usually X=Y.

Actually no, it doesn't say that. The source version is not an
environment specification, it's a language level specification
(5=generics, 6=@Override in interfaces, 7=Project Coin features, etc).
And the target version specifies the compatible VMs. There is no
assumption on the available libraries.

> The safe thing to do as a builder is to build with a Java version that
> matches the source version set in the POM.

Sure that would be ideal, but that's not the reality. In the real world
folks have to compile DBCP 1.x with Java 7 because they can't support
Java 6 any longer.

> The result of using a new Java version than that is undefined because who
> knows what future JDKs will require.

That's our responsibility as developers and maintainers to ensure our
components are still usable with newer versions of Java. At least for
the components with a significant user base, and DBCP is clearly one of

Honestly, if we can't release a Java 7 compatible version of DBCP 1.x we
should stop pretending that the source code is our primary deliverable,
because this source code has been broken with the latest version of Java
for nearly 2 years now.

Emmanuel Bourg

View raw message