@Supported design issues

[Joseph Darcy]

On 9/10/2013 10:08 AM, David M. Lloyd wrote:
> On 09/10/2013 11:54 AM, Mandy Chung wrote:
>> On 9/10/13 9:47 AM, Joe Darcy wrote:
>>>
>>> On 9/10/2013 6:28 AM, Alan Bateman wrote:
>>>> On 06/09/2013 04:23, mark.reinhold at oracle.com wrote:
>>>>> :
>>>>> Well, looking ahead to when the platform will be composed of modules,
>>>>> those modules will declare that they "export" some API elements, but
>>>>> not others.  An @Exported annotation would help get people used to
>>>>> the expected future terminology.
>>>>>
>>>> @Exported is quite good, and consistent with where this is likely 
>>>> going.
>>>>
>>>> Joe - what would you think of just running with this? I'm anxious
>>>> that we decide on this soon so that we don't run out of time in jdk8.
>>>>
>>>
>>> I don't object to using @Exported.
>>
>> I like @Exported as well.
>
> If we're framing it in terms of modules, I think it would make more 
> sense to have exporting be default and "hidden" be opt-in.
>
> And, while we're at it, "hidden" really ought to apply at a package 
> level, not a class level.
>
> In other words: don't make this about modularity.

To bring in some of the initial context, this feature is about 
documenting and formalizing the historically unclear 
exported-ness/supported-ness of types in the com.sun.* packages. Some 
com.sun.* types are intended to be used outside of the JDK while others 
are not.

To bring clarity to this situation, I'd like to see each type and 
package in com.sun.* either have an explicit @Exported(true) XOR 
@Exported(false) annotation applied to it. This make a clear statement 
around the intentions of the type and will allow better tooling to be 
written.

-Joe