Motivation for type-level exports

[Eric Johnson]

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.

On top of that, I *know* I've seen cases within the JDK documentation 
itself where a class has been marked as "not for use". I've not seen 
this recently, so I wonder if those classes have been hidden by clever 
use of the javadoc tool.

One way of addressing this question would be to annotate the class 
itself, but OSGi doesn't do this, I believe, because it would increase 
load times.

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

Because there are awkward circumstances in Java where you need to make a 
class public within a package in order to access details from that 
package in other packages of the same module, but you just don't want to 
make the class part of the published API. Not having run into this 
recently, I cannot give you a good example off the top of my head, my 
apologies. Typically you're going to see this problem as part of 
attempting to modularizing existing code bases.

-Eric.