Motivation for type-level exports

[David Holmes]

On 5/11/2011 3:04 AM, Neil Bartlett wrote:
> Thank you Jesse. All reasonable responses are welcome, not just "official" ones.
>
> Restricting visibility of a type that is currently public does not seem like a requirement that could be motivated by JDK modularisation, since it would break compatibility for any existing consumers of that type. It's possible that there is a need to introduce *new* types in the JDK modules that will be public but non-exported, though that seems unlikely.

One of the use cases has always (AFAIK going way back to early days of 
Java module/superpackage work) been the ability to hide, within a 
module, types that are public only because it is the only way they can 
be shared between related packages.

> In application code, why not just have package-level exports, i.e. entire packages are either exported or private?

Because that doesn't allow cross-package sharing.

David
-----

> Regards
> Neil
>
>
>
> On Thursday, 3 November 2011 at 23:35, Jesse Glick wrote:
>
>> Not an official response but my guess:
>>
>> On 11/03/2011 06:20 PM, Neil Bartlett wrote:
>>> It seems that the only possible need for type-level exports could be
>>> one or both of the following:
>>>
>>
>>
>> 3. To permit the type to be visible to other packages in the same module, but not to other modules. In my experience this is a rather common need. If only
>> package-granularity exports are available, you can still get around this, but it is tricky, requiring a special trampoline [1]. A new access modifier intermediate between
>> public and default would be more intuitive, I think.
>>
>> [1] http://wiki.apidesign.org/wiki/FriendPackages
>