DRAFT: Project Jigsaw: The Big Picture (part 1)

[Sebastian Sickelmann]

Hi,

thank you for the good big picture. I know have a somewhat better 
feeling what jigsaw will/can be.

I have a few questions/suggestions:

 > A series of |exports|, |requires public|, and |permits| clauses at 
the top syntactic
 > level of a module declaration defines the module’s /default view/. 
Further
 > views of a module’s bindings can be defined using the |view| construct,
 >which specifies a view name together with a bracketed list of exports
 >and permits declarations:

|>module bar {
>     requires foo;
>     exports bar;
>     view bar.internal {
>         permits baz;
>         exports bar.private;
>     }
>}
|

 >The |bar| module now defines two views. The default view, available
 > by referencing the module name |bar|, is the same as before—it’s
 > as if the declaration also said |view bar { exports bar; }|. The new 
view,
 > named |bar.internal|, is available only to the |baz| module. It exports
 > all public types in the |bar.private| package. It also exports all 
public
 > types in the |bar| package because the non-default views of a module
 > inherit the |exports| clauses of that module’s default view.

 >A non-default view never has |requires| clauses.

 >A non-default view cannot declare its version; it inherits the version,
 > if any, of its containing module.

 >A non-default view does not inherit the |permits| clauses, if any, of its
 > containing module.


What happens in the following example?

|module bar {
     requires foo;
||     permits baz;
||     exports barpackage;
|||
|     view bar.publicview {
         exports barpackage.public;
     }
}

Module bar only allows baz to access the module. Through the view bar.publicview every module can access barpackage and barpackage.public.
|
Isn't here a discrepancy not to inherit the permits clauses of the containing module?

|What happens to the local-dependencies? baz can access|package-private types in barpackage. Can baz also localy depend on barpackage.public?




My next question goes to reexported and version numbers:

|>module foo {
>     exports foo;
>}
>
>module bar {
>     requires public foo;
>}
>
>module baz {
>     requires public bar;
>}
>
>module buz {
>     requires baz;         // Can also use foo's exported types
>}|

What would happen if definition of buz and bar are the following:

|module bar {
     requires public foo @ 1.0;
}
|

|module buz {
     requires baz;         // Can also use foo's exported types
     requires foo @>= 2.0;
}

The use case is: buz want to use functionality of baz.
baz also provides some functionality for which foo must be reexported. But buz is not using this functionality.
But buz uses some functionlity in foo that is only supported since version 2.0 of foo.
Can buz override the reexported dependency of foo at 1.0 to foo@>=2.0?

We can get in the the same situation if an old version of bar doen't need foo at all. buz already uses foo @>= 2.0
Now buz bar starts using foo @ 1.0 and unintentionally reexportes foo.
||Can buz override the reexported dependency of foo at 1.0 to foo@>=2.0?
|

|-- Sebastian
|


Am 21.12.2011 00:28, schrieb mark.reinhold at oracle.com:
> I've started drafting an overview of the current state of Jigsaw.
> The first part is attached below, and also available on the web:
>
>    http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01
>
> Comments, questions, and suggestions welcome.  Flames will be ignored.
>
> - Mark