exports directive

[David Holmes]

On 19/06/2012 9:12 PM, Neil Bartlett wrote:
> +1
>
> Amongst OSGi developers using the "bnd" tool (which generates
> MANIFEST.MF from a descriptor file), the use of wildcards for exports
> is widely held to be an anti-pattern. It obscures the actual exports
> and leads to the module author exposing more implementation details
> than intended.

I think whether you have wildcards or use explicit lists, the basic 
problem being described is the inability to readily validate that what 
you wrote is what you intended - whether you left something out, or 
added something extra in.

I would have thought, perhaps naively, that the majority of subpackages 
would be for exporting, and so ease of use should focus on making it 
easy to declare those exports.

David
-----

>
> On Tue, Jun 19, 2012 at 11:06 AM, Jaroslav Tulach
> <jaroslav.tulach at oracle.com>  wrote:
>> Dne Út 19. června 2012 13:17:24, David Holmes napsal(a):
>>> On 19/06/2012 1:10 PM, Mandy Chung wrote:
>>>> On 6/18/2012 7:20 PM, David Holmes wrote:
>>>>> Does export work like a prefix such that
>>>>>
>>>>> exports foo;
>>>>>
>>>>> means the module exports all types in package foo, plus all types in
>>>>> all subpackages of foo? Or do I need to use multiple exports
>>>>> directives, or wildcards?
>>>>>
>>>> |exports| takes a qualified identifier indicating a package name. You
>>>>
>>>> need to use multiple |exports| directives to list its subpackages:
>>>> |module foo {
>>>>
>>>> exports foo;
>>>> exports foo.spi;
>>>> exports foo.util;
>>>> }
>>>>
>>>>> And is this documented somewhere?
>>>>
>>>> http://openjdk.java.net/projects/jigsaw/doc/lang-vm.html
>>>> http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01
>>>
>>> Thanks Mandy!
>>>
>>> Annoyingly tedious to have to list all the subpackages directly though.
>>> Libraries that make extensive use of subpackages for grouping things
>>> will need to use long exports lists. Some kind of wildcard support would
>>> be quite useful I think.
>>
>> A tools perspective: Wildcards are pain to support. Example: just by looking
>> at module-info.java one cannot deduce list of exported packages. One needs to
>> examine all module source files. Tedious.
>>
>> A user perspective: While wildcards save some time initially, they usually
>> bite you back after few years of maintenance. Also they don't work well when
>> somebody adds org.myorg.myexportedapi.internal package, which is a common
>> pattern used by some open source projects.
>>
>> -jt
>>