Lance J. Andersen wrote: > Prior versions of the JDBC specification were not clear or concise as to > what a developer and or a user could expect. This as a JDBC driver > developer while at Sybase i found extremely frustrating. > > These methods have been in the JDBC spec since 1.0. We will not be > removing them from the spec and just because something is deprecated, it > does not mean that it should not be implemented or ignored. It just > means that there are alternative methods that are recommended. Also in > my working with the Java SE team, they discourage deprecating methods > via the javadoc tag as it adds unnecessary noise at compile time where > as a simple note in the spec/javadoc can point users to the preferred > method.
So the @deprecated tag is now deprecated! :-) > > As far as your question below, it is impossible to determine what > methods are and are not required from the JDBC 3.0 specification. This > is something that i have addressed in JDBC 4.0. DJD question> According to which section of JDBC 3.0? Then this is about JDBC 4.0 compliance and not JDBC 3.0. I don't see how you can change the rules for JDBC 3.0 compliance with a release of the JDBC 4.0 specification. I believe that Sun in the past has confirmed JDBC drivers including Derby & Cloudscape pre-open source as being JDBC 3.0 compliant, seems wrong to say, oh now there's additional work to do. Dan.
