Rick Hillegas <[email protected]> writes: > 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?
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
