db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: using ClientDataSource on Java 6
Date Tue, 09 Nov 2010 18:27:54 GMT
Rick Hillegas <rick.hillegas@oracle.com> writes:

> Knut Anders Hatlen wrote:
>> Rick Hillegas <rick.hillegas@oracle.com> writes:
>>
>>   
>>> The Admin Guide says that you can use the ClientDataSource class on
>>> all Java SE platforms, including Java 6:
>>> http://db.apache.org/derby/docs/10.6/adminguide/adminguide-single.html#cadminnsdatasources
>>>
>>> I think that this may work if verification is lazy and does not notice
>>> that ClientDataSource does not satisfy the full Java 6 contract for
>>> javax.sql.DataSource (ClientDataSource does not implement
>>> java.sql.Wrapper). I believe that a runtime with aggressive
>>> verification could fail to load ClientDataSource.
>>>
>>> Does this sound right to you?
>>>
>>> Elsewhere in our user documentation, we do advise applications to use
>>> the *40 DataSources when running on Java 6.
>>>     
>>
>> ClientDataSource40 extends ClientDataSource, so if a JVM fails to load
>> the ClientDataSource class, I suppose it won't be able to load
>> ClientDataSource40 either.
>>
>> It would also fail to load the Connection/Statement/ResultSet classes in
>> any JDBC 3.0 driver, so the backward-compatibility story for such a JVM
>> would be poor.
>>
>>   
> That sounds right. I will stop worrying about this one.
>
> What should we do about the issue Dag brings up? The Admin guide tells
> people to use ClientDataSource. That advice is repeated in the
> Developer's guide:
> http://db.apache.org/derby/docs/dev/devguide/devguide-single.html#rdevresman79556
> But the javadoc advises people to use DataSource implementations
> specific to the JDBC level of their VM. The discrepancy between the
> user guides and the javadoc is confusing people and that is why I
> kicked off this thread. I think that the verbiage in the Developer's
> guide is the clearest statement about what is expected to work. Should
> we just add that verbiage to the javadoc headers for our public
> DataSource implementations?

Yes, that sounds reasonable. The only difference between the *DataSource
classes and the *DataSource40 classes is the presence of isWrapperFor()
and unwrap(). Those methods don't add much value in our implementation,
so most users would probably be fine with *DataSource.

-- 
Knut Anders

Mime
View raw message