Motivation for type-level exports

[David M. Lloyd]

On 11/04/2011 03:21 PM, Eric Johnson wrote:
> Hi Neil,
>
> On 11/4/11 6:04 PM, Neil Bartlett wrote:
>> 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.
>
> I haven't studied this question in the context of modularizing the JDK,
> but I've seen this question arise in the context of OSGi. However, I
> think you're almost certainly overlooking all of the "com.sun.*" classes
> in the JDK that are an implementation detail, but that occasionally end
> up being used by clients. It is exactly this problem - the fact that
> Java cannot make the distinction between a class which is "public"
> within a module, and "published" outside of a module. I'm willing to bet
> that virtually every single "public" com.sun.* class falls into this
> precise category.

This is easily solved using package-level exports though and need not 
delve into the layer of per-class exports.  In JBoss AS we have a module 
which represents the standard JDK, and separate modules for the 
proprietary classes that vary based on vendor.

-- 
- DML