On Dec 2, 2011, at 10:54 AM, David Schlosnagle wrote:
> 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.* :)
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
> <[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
>
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
[email protected]
