@Supported design issues

David M. Lloyd david.lloyd at redhat.com
Wed Sep 11 02:50:13 UTC 2013

On 09/10/2013 06:26 PM, Joseph Darcy wrote:
> 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.

I'm aware of that; however I guarantee you that if you try to munge this 
functionality up with the concept of exported classes or packages before 
the module system is realized, it's going to end up wrong and we'll have 
yet more dead cruft in the API.

> 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.

"Plus one" for this, modulo a request to not use the term "Exported" 
and/or not make this annotation part of the public API.

More information about the core-libs-dev mailing list