Motivation for type-level exports
Richard S. Hall
richard.s.hall at oracle.com
Tue Nov 8 19:56:12 PST 2011
On 11/8/11 16:40, mark.reinhold at oracle.com wrote:
> 2011/11/4 10:04 -0700, njbartlett at gmail.com:
>> ...
>>
>> 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.
> Correct.
>
>> 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.
> Agreed.
>
> We haven't, in fact, run across any situations in the JDK modularization
> work that absolutely require type-level exports.
>
>> In application code, why not just have package-level exports,
>> i.e. entire packages are either exported or private?
> Package-level imports are certainly simpler, and they do appear adequate
> for many, if not most, use cases both in the JDK and in applications.
>
> When we introduced export clauses into the prototype Alex argued, and
> I agreed [1], that we should use type granularity rather than package
> granularity. That approach is theoretically appealing but it turns out
> to be difficult to implement efficiently (as we learned from Mandy's
> prototype work last summer); it also makes it more difficult to reason
> about the semantics of module graphs.
>
> I strongly suspect that we'll drop type-level exports unless some actual
> use cases crop up.
Even though OSGi supports type-level filtering from exported packages, I
think it is safe to say that it is rarely used and few would miss it if
it never existed in the first place.
-> richard
>
> - Mark
>
>
> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-April/001224.html
More information about the jigsaw-dev
mailing list