RFR: 8335989: Implement Module Import Declarations (Second Preview) [v3]

[Maurizio Cimadamore]

On Mon, 14 Oct 2024 12:46:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
>> 
>> The main changes are:
>> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
>> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
>> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
>> 
>> import module java.base;
>> import module java.desktop;
>> ...
>> List l;//ambigous
>> 
>> but:
>> 
>> import module java.base;
>> import module java.desktop;
>> import java.util.*;
>> ...
>> List l;//not ambigous, reference to java.util.List
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 1141:

> 1139:             return true;
> 1140:         } else if (sym.kind == TYP && toplevel != null) {
> 1141:             for (Scope scope : new Scope[] {toplevel.namedImportScope,

I wonder if we could deal with this with a compound scope? (and avoid the loop)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1808556685