On Fri, Dec 2, 2011 at 8:19 AM, Lance Andersen - Oracle < [email protected]> wrote:
> Adding @Deprecated changes the signatures so I need to coordinate any > changes as it will result in TCK signature failures. This is something I > will most likely do as part of the JDBC 4.2 work after giving the JDBC EG a > chance for input. > Lance, I figured it was worth a shot to try and piggy back on your changes to cleanup the rest of java.sql.* :) I assume it is the @Deprecated annotation's retention runtime value that introduces TCK signature compatibility issues, is that correct? If so, that is an interesting catch-22 when the idea behind @Deprecated is to maintain a backward compatible API for some period to be determined to the API provider. It seems like this might be worthwhile mentioning in the deprecation guide [1], and maybe even additions to Joe Darcy's excellent treatises on compatibility [2] [3]. I completely understand wanting to wait for the appropriate approvals to move forward with the remaining cleanup. On Fri, Dec 2, 2011 at 9:14 AM, Lance Andersen - Oracle < [email protected]> wrote: > Here is the diff for DriverManager, I won't be pushing another webrev > unless the word is to go ahead and add @Deprecated to the com/* classes of > the RowSet RI or there is another change requested that is more detailed: > That looks good to me, unfortunately I don't think I can be used as a reviewer. Thanks, Dave [1]: http://docs.oracle.com/javase/6/docs/technotes/guides/javadoc/deprecation/deprecation.html [2]: http://blogs.oracle.com/darcy/entry/kinds_of_compatibility [3]: http://blogs.oracle.com/darcy/entry/release_types_compatibility_regions
