Review request for runtime support for exports

[Richard S. Hall]

On 5/10/11 19:52, Mandy Chung wrote:
>
>
> I have implemented the runtime support for "export" (see the grammar
> in [1] and [2])
> that also replaces the "requires public" re-exports mechanism.
>
> Jon, I modified a few javac files for the new exports() method added in
> the ModuleInfo class.
>
> Webrev at:
>    http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/exports-runtime
>
> Changes include:
> 1. Context stores a map from a remote class to the supplying context.
> 2. Configuration stores the list of remote classes rather than remote
> packages.
>     - This is to handle the case that a module A only exporting some
> public types
>       but keep a few public types invisible and another module B
> re-exporting A
>       using the wildcard.
>
> module A {
>      export a.A;  // a.B class is public but not exported
> }
>
> module B {
>      requires A;
>      export a.*;  // what classes should module B re-export?
> }
>
> What types should B re-export?
>
> 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.

>
> 3. Linker determines if a local class is exported by checking it
> against the
>     ModuleExport attribute of its module info.  To determine if a
> remote class
>     is re-exported from a supplying context, it will check against the
> exports
>    defined in all module infos in that context.
>
> 4. PathLinker has to do some analysis to find all remote contexts
> supplying
>     public types directly and indirectly.  The way I implemented is to
> compare
>     the exports from a context and a given supplier (i.e. the required
> module's
>     context); it re-exports the types from the supplier when there is
> one matching
>     export.
>
> 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.

-> richard

>
> I added a test case (split-package) in _Configurator.java test for what
> described above.  The resolution succeeded in the current implementation.
>
> Thanks
> Mandy
>
> [1]
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-March/001201.html
> [2]
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-April/001225.html
>