You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <ri...@oracle.com> on 2010/11/09 15:44:34 UTC
using ClientDataSource on Java 6
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.
Thanks,
-Rick
Re: using ClientDataSource on Java 6
Posted by "Dag H. Wanvik" <da...@oracle.com>.
Rick Hillegas <ri...@oracle.com> writes:
> Elsewhere in our user documentation, we do advise applications to use
> the *40 DataSources when running on Java 6.
That's at least what it says in the Javadoc of ClientDataSource40:
(snip)
* Use these DataSources if your application runs under
* JDBC4.0. Use the corresponding ClientDataSource, ClientConnectionPoolDataSource, and
* ClientXADataSource classes if
* your application runs in the following environments:
* <p/>
* <UL>
* <LI> JDBC 3.0 - Java 2 - JDK 1.4, J2SE 5.0
* <LI> JDBC 2.0 - Java 2 - JDK 1.2,1.3
Dag
Re: using ClientDataSource on Java 6
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@oracle.com> writes:
> Knut Anders Hatlen wrote:
>> Rick Hillegas <ri...@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
Re: using ClientDataSource on Java 6
Posted by Rick Hillegas <ri...@oracle.com>.
Knut Anders Hatlen wrote:
> Rick Hillegas <ri...@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?
Thanks,
-Rick
Re: using ClientDataSource on Java 6
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@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.
--
Knut Anders