Motivation for type-level exports

[Peter Kriens]

OSGi can filter classes from an exported package (Core 3.7.8). 

Kind regards,

	Peter Kriens

On 4 nov. 2011, at 21:21, 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.
> 
> 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.
>