Motivation for type-level exports
David M. Lloyd
david.lloyd at redhat.com
Thu Nov 3 18:57:26 PDT 2011
On 11/03/2011 06:35 PM, 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
> . A new access modifier intermediate between public and default would
> be more intuitive, I think.
>  http://wiki.apidesign.org/wiki/FriendPackages
I think you're confusing the issue of visibility with accessibility.
Your #3 is accommodated via a new access level - "module" - which would
restrict *accessibility* of a class but not *visibility* of that class.
Given the presumed availability of the new module-wide access level,
your #3 is satisfied wholly, yet Neil's question is unanswered.
Leaving aside the unmitigated disaster that inevitably awaits us in
regards to the location and disposition of module metadata in the
current prototype, exports (or rather the lack of them) are generally
more useful in avoiding linkage problems than as a security mechanism.
But our experience has shown that controlling exports at a package level
is more than adequate for this task for what we expect to be a typical
module library distribution. We've only needed to add hooks for
type-level visibility controls for the purposes of our OSGi implementation.
More information about the jigsaw-dev