db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: conflict between Derby API and JDBC 4.0
Date Mon, 10 Oct 2005 19:24:37 GMT
Thanks, Dan. For the record, I think that this affects 
org.apache.derby.jdbc as follows:

- ClientConnectionPoolDataSource (implements 
javax.sql.ConnectionPoolDataSource, which extends 
javax.sql.CommonDataSource, which mentions QueryObjectGenerator, which 
is new to 1.6 and mentions generics).
- ClientDataSource (implements javax.sql.DataSource, which mentions 
generics)
- ClientXADataSource (same as ClientDataSource)
- EmbeddedConnectionPoolDataSource (same as ClientDataSource)
- EmbeddedDataSource (same as ClientDataSource)
- EmbeddedSimpleDataSource (same as ClientDataSource)
- EmbeddedXADataSource (same as ClientDataSource)

Regards,
-Rick

Daniel John Debrunner wrote:

>Rick Hillegas wrote:
>
>  
>
>>I would like advice on how to handle the conflict between the public
>>Derby API and JDBC 4.0. This issue was raised by Dan in his comments on
>>bug 587.
>>
>>A) Does this issue block the submission of the 587 fix?
>>    
>>
>
>I don't think so. But I think we would want to resolve the issue before
>release a Derby version that contained this code. Though potentially
>resolution could wait until JDBC 4.0 was official.
>
>  
>
>>B) How do we want to handle this conflict in 10.2?
>>
>>The problem is that some javax.sql interfaces are incompatible between
>>jdk1.4 and jdk1.6. A class implementing one of these interfaces can't
>>run on both the 1.4 and 1.6 vms. This is a showstopper for Derby because
>>i) our public API contains classes which implement these incompatible
>>interfaces and ii) we ship a single jar which we expect will run on all
>>supported vms. The comments on bug 587 suggest some solutions:
>>
>>1) Some, as yet not understood, classloader trick.
>>
>>2) Abandon requirement (ii) and release separate Derby deployments for
>>1.4 and 1.6.
>>    
>>
>
>I would say 2) is out, it seems overkill for a single class to drive a
>switch to multiple/different versions for different environments.
>
>
>  
>
>>3) Change our public API.
>>
>>I would appreciate some discussion of this serious problem.
>>    
>>
>
>Beyond that, I will think more :-)
>
>Dan.
>
>  
>


Mime
View raw message