JDK 8 code review request for JDK-8025913 - Rename jdk.Supported to jdk.Exported

[Joe Darcy]

On 10/17/2013 10:45 PM, Joe Darcy wrote:
> Hello,
>
> Following up on the earlier feedback, please review the patch below 
> with proposed clarifications to jdk.Exported.
>
> Thanks,
>
> -Joe
>

Responding to Paul's comment on the earlier version, I've reordered and 
slightly amended the text as shown in the patch below.

Thanks,

-Joe

diff -r 7af634b1fc5b src/share/classes/jdk/Exported.java
--- a/src/share/classes/jdk/Exported.java    Thu Oct 17 19:10:19 2013 -0700
+++ b/src/share/classes/jdk/Exported.java    Mon Oct 21 09:32:34 2013 -0700
@@ -38,7 +38,30 @@
    * com.sun.*} are official parts of the JDK meant to be generally
    * usable while other portions of {@code com.sun.*} are not.  This
    * annotation type allows those portions to be easily and
-  * programmaticly distinguished.
+  * programmatically distinguished.
+  *
+  * <p>If in one release a type or package is
+  * <code>@Exported(true)</code>, in a subsequent major release a type
+  * or package can transition to <code>@Exported(false)</code>.
+  *
+  * <p>If a type or package is <code>@Exported(false)</code> in a
+  * release, it may be removed in a subsequent major release.
+  *
+  * <p>If a top-level type has an <code>@Exported</code> annotation,
+  * any nested member types with the top-level type should have an
+  * <code>@Exported</code> annotation with the same value.
+  *
+  * (In exceptional cases, if a nested type is going to be removed
+  * before its enclosed type, the nested type's could be
+  * <code>@Exported(false)</code> while its enclosing type was
+  * <code>@Exported(true)</code>.)
+  *
+  * Likewise, if a package has an <code>@Exported</code> annotation,
+  * top-level types within that package should also have an
+  * <code>@Exported</code> annotation.
+  *
+  * Sometimes a top-level type may have a different
+  * <code>@Exported</code> value than its package.
    *
    * @since 1.8
    */