exports directive

[Neil Bartlett]

+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.


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
>