commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [dbco] 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 Fri, 11 Jan 2013 14:33:42 GMT
On 1/11/13 4:55 AM, Jörg Schaible wrote:
> Hi Mark,
>
> Mark Thomas wrote:
>
>> On 11/01/2013 11:31, sebb wrote:
>>> On 11 January 2013 02:38, Phil Steitz <phil@steitz.com> wrote:
>>>> On 1/10/13 8:57 AM, markt@apache.org wrote:
>>>>> Author: markt
>>>>> Date: Thu Jan 10 16:57:07 2013
>>>>> New Revision: 1431496
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=1431496&view=rev
>>>>> Log:
>>>>> Update DBCP2 to require JDBC 4.1 (Java 7) since Java 6 is close to end
>>>>> of life and a DBCP2 release is still a little way off.
>>>> Probably should have talked about this on the list.  Oh, I guess we
>>>> are.  In that case, here is my +1.
>>> I don't understand the rationale for requiring JDBC 4.1 - does it
>>> offer significant benefits over the previous version?
>> Nothing significant that I have found so far.
>>
>>> Or is it that applications written to use the previous version of JDBC
>>> won't even run on Java 7?
>> They should run but DBCP won't compile on Java 7 unless the JDBC 4.1
>> methods are implemented (hence the gump nags we have been getting for a
>> while). There is also the risk that an app written compiled against Java
>> 7 tries to use one of the JDBC 4.1 methods. That would trigger a
>> run-time exception.
>>
>>> I know that the JDBC API has been changed in ways that don't respect
>>> upward compatibilty in the past - has that happened again?
>> Yes. As it has with every new JDBC release that I can recall.
>>
>>> Although Java 6 is close to EOL, I suspect a lot of commercial sites
>>> will remain on it long after EOL.
>> There is the option (if someone wants to scratch this particular itch -
>> I don't) to add similar filtering as there is in DBCP1 to support dual
>> builds for JBDC4 and JDBC4.1.
> Why not? DBCP did set the precedence with active 1.3.x and 1.4.x series. No 
> reason why we should not have now 1.5.x (JDBC 4.1) and 1.4.x (JDBC 4.0). 
> However, I'd skip the maintenance of 1.3.x then.

Patches welcome!  I think this would be a good feature to have; but
someone has to actually do the work.  I would look carefully at the
question though of whether or not we have to actually split the
series.  IIRC, we were forced into in the 1.3/1.4 split by really
incompatible JDBC changes.  Just added methods we were able to
accommodate before with filters.  In any case, if we ended up
splitting here it would be 2.0.x / 2.1.x.

Phil
>
>> My primary driver is that I want to get a decent concurrent connection
>> pool based on DBCP into Tomcat 8. Tomcat 8 implements Servlet 3.1 which
>> requires Java 7 so I need DBCP2 to build against Java 7 and I'd rather
>> not continue the current hack in the Tomcat build of patching the source
>> to add the methods.
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message