7116445: Miscellaneous warnings in the JDBC/RowSet classes

Fri Dec 2 16:06:39 UTC 2011

On Dec 2, 2011, at 10:54 AM, David Schlosnagle wrote:

>  On Fri, Dec 2, 2011 at 8:19 AM, Lance Andersen - Oracle <Lance.Andersen at oracle.com> 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.* :) 

Appreciate the suggestion.

> 
> I assume it is the @Deprecated annotation's retention runtime value that introduces TCK signature compatibility issues, is that correct?

Yes, here is the reason why:

@Documented
@Retention(value=RUNTIME)
@Target(value={CONSTRUCTOR,FIELD,LOCAL_VARIABLE,METHOD,PACKAGE,PARAMETER,TYPE})
public @interface Deprecated

why  Here is @Documented

@Documented
@Retention(value=RUNTIME)
@Target(value=ANNOTATION_TYPE)
public @interface Documented
Indicates that annotations with a type are to be documented by javadoc and similar tools by default. This type should be used to annotate the declarations of types whose annotations affect the use of annotated elements by their clients. If a type declaration is annotated with Documented, its annotations become part of the public API of the annotated elements.
Since:
1.5

As you can see this results in an API change which would result in the signatures changing.  This type of change would be flagged by the signature tests so we would not want to do this in say JDK 7.  It would be OK for JDK 8 but I would not want to do it as part of the cleanup changes.

It is interesting that the behavior is different between @Deprecated vs @deprecated(javadoc mark up) and I have had previous discussions on this as one vendor made this innocent change in a standalone technology and then could not pass the signature tests for a given TCK.

Again, my desire is to do this soon,  and might for the com.* classes assuming Alan/Stuart see no issue as part of this push

Many thanks for your time

Best
Lance
> 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 <Lance.Andersen at oracle.com> 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
> 

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com