Dmitry Serebrennikov wrote:

>
>>
>> Well, I can think of one thing I would like, some way for the 
>> packages contained in a JAR file be able to inform the underlying 
>> runtime not only its external dependencies, but also what it provides 
>> (or what it exposes). Due to limitations in the Java 
>> visibility/protection rules, sometimes it is not possible to avoid 
>> making implementation API public because you are forced to declare 
>> classes/methods as public if you need to use them from more than one 
>> package.
>
>
> Woudln't it be great if this was addressed at the language level? 
> Something like declaring "friend" packages or something like that. 
> Then the public modifier would basically fulfil the need for this kind 
> of "provides" or "exposes" declaration?


This could certainly be one way to implement it, but I don't think we 
are going to extend the JVM.

> Well, maybe not. If you package a few packages together into a new 
> library, each package might have its public interface, but that 
> doesn't mean you want those methods as part of your library interface 
> too. So the need for "provides" declaration goes beyond the package 
> visibility related limitations it seems.


Yes, there are subtle issues here. The benefit of using a JAR 
manifest-based approach is that it works with legacy code and does allow 
for easier composition of third-party libraries. In theory it may sound 
like a good idea to really lock a module down so that outsiders cannot 
access its internals, but maybe in reality it would not be good to 
completely lock it down. For example, by using a JAR manifest approach, 
it is possible for me to develop some extension to a third-party library 
that uses its non-public API to improve performance. I could then 
package this as a module to properly encapsulate it again. In this way, 
I accept the responsibility of using non-public API, but we can still 
protect others from accidentally using it.

So, perhaps having two views of a JAR file, one as just a library and 
the other as a module, is more flexible. Just a thought.

> Doesn't Eclipse do something like this?


I don't know for sure, but I have heard reports that Eclipse plugins 
expose all of their internals.

-> richard