Knut Anders Hatlen wrote:
Rick Hillegas <[email protected]> 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
