Review request for runtime support for exports

[Mandy Chung]

  On 05/11/11 12:41, Richard S. Hall wrote:
> On 5/10/11 19:52, Mandy Chung wrote:
>>
>> I think module B should only propagate the visible exported types from A
>> that's what I currently implement.
>
> Yes, I think that is the only reasonable thing.
>
> However, in my experience reexporting is generally not a good thing 
> since it hides the actual dependencies of a module and creates an 
> additional form of breaking changes since modules now have to consider 
> their dependencies as part of their public API that cannot be changed 
> without breaking downstream consumers.
>

I can imagine that.

"reexports" would be useful when a library wants to export its internal
APIs for internal modules to use while it defines another module to export
its external supported interface.  These internal modules only permit a
known list of modules to use.

For example, jdk.boot module exports java.lang.* and sun.* API (and
many others) since other jdk modules also use sun.* API.
jdk.boot only permits internal jdk modules to use while we will define
jdk.base to re-export java.lang.* and other java.* APIs for applications 
to use.

>>
>>
>> During testing, I found that the resolver detects the split-package 
>> issue
>> only if more than one module contains a visible type in the same 
>> package.
>> In other word, if module A exports a public type a.A and module B has
>> a public type a.B but not exported, when a module Foo requires both
>> A and B, what is the expected behavior for the resolver?   How should
>> "local" and "permits" be used in this case?
>
> Additionally, what about overlapping content? Is that forbidden? If 
> not, then ordering becomes important.
>

Good question.  Mark, Alex, what is the intended behavior?

As described in the specification of module configuration process,
    
http://cr.openjdk.java.net/~mr/jigsaw/api/org/openjdk/jigsaw/Configurator.html

    Multiple modules defining types in the same package must all be assigned
    to the same context, so that they all wind up in the same class loader at run
    time. This allows us to reason about, and store, cross-context dependences
    in terms of package names rather than individual type names, saving both
    time and space.

    A type definition in a module may be shadowed only by some other module
    in the same context, and the shadowing definition must dominate all other definitions.

The intra-context dominant-shadow algorithm is not implemented.   But it
seems that the intent is to allow the same type defined in module A and B
as long as they are in the same context (requires 'local').

Mandy